New PX4 - ROS2 Bridge Documentation update

[akshata-01]

• Intro
• Why this approach?
• Architectural Overview
• A note in the RTPS has been added.

This PR is conditional on:

• Associated PR msg ROS2 compatibility, microdds_client improvements (timesync, reduced code size, added topics, etc), fastrtps purge PX4-Autopilot#20227

[hamishwillee]

NOte, I have converted into a "draft" as we can't merge it until it is finished

[akshata-01]

Have the changes that remove micro rtps and add micro_dds been merged into PX4? What is the PR for that?

NOte, I have converted into a "draft" as we can't merge it until a) it is finished and reviewed b) the associated PR is merged.

Sure, Here

[hamishwillee]

These are some architecture overview summaries I want checked with @TSC21 . This is what provides me the delta to understand what is the difference in the microRTPS vs microDDS options.

XRCE Bridge

Pretty much the same as the old model in that you have a fastCDR channel and the client/agent bidirectionally translate uorb to DDS

Presumably client source code is generated based on uorb and included in PX4.

• Previously for a non-ROS2 app the agent code was created at same time for same messages defined in yaml. YOu could build whenever. However for ROS 2 you needed different IDL, so instead the process generated px4_msgs and px4_ros_com, from which you could build agent code that would be compatible with the client on PX4.
• This was needed because DDS and ROS2 had a different IDL/message structure. SO a ROS2 app was different. It also needed a consistent API to match against.

So what is changed here is that you only need one form of IDL for DDS and no different format for ROS2. This is because the differences in forms are handed by the integration service to ROS2.

What is cool about this is that in the new version you can build the agent off a release, since all the messages to share etc are known. There is no need to maintain px4_ros_com.

1. That all about right?
2. Is the set of messages that are supported still built based on yaml as per http://docs.px4.io/main/en/middleware/micrortps.html#supported-uorb-messages ?

microROS

So microROS is a similar client/agent architecture except that it translates from ROS2 to uorb, and presumably abstracts all the IDL stuff.
My guess is that it uses the same uorb, but it does away with templates etc because you know the target IDL.

Again, you don't need to do anything to maintain compatibility because you build off a release. About right?

Same kinds of questions thought - confirm build messages based on same YAML source.

General questions

1. Are microROS and microDDS built using the same yaml definition of the uorb topics?
2. I presume that we would recommend using DDS for a DDS network that might also connect to ROS, but if we know we're connecting to a pure ROS network we use microROS?
3. Can both be present and enabled on PX4 at the same time? If not, how enable/disable?
4. There was a topic "manually generating client/agent'. Is this still something we want to do and can do?
5. Any other big picture things to mention?

[hamishwillee]

Note, this was how to install the old toolchain. We will need to replaces this with a new doc. I have deleted the doc. I have not redirected - just created one redirection for the main document.

[hamishwillee]

Note the title contains RTPS. Touched this because we will need to rewrite this example for the new architecture.

[hamishwillee]

Deleted link. Doc still exits, but just redirects to the DDS doc. That has a note explaining where FastRTPS went.

[hamishwillee]

We may need to replace this link with a new doc. Could well have the same name. But will reflect microDDS.

[TSC21]

I believe we don't need this anymore

[hamishwillee]

Note, touched this because the document refers to RTPS. Need to review whole doc verify status for XRCE microDDS and microROS.

[hamishwillee]

Note rtps config. Is there a new config? What are the options after the change?

[beniaminopozzan]

All rtps config have been removed, the microdds_client is included by default in most of the boards but the user has to manually start it acting on the appropriate parameters.
In simulation, the module is automatically started using udp protocol and port 8888

[TSC21]

What @beniaminopozzan said

[hamishwillee]

@beniaminopozzan Thanks. I presume by appropriate parameters etc you mean the command line here: http://docs.px4.io/main/en/modules/modules_system.html#examples-3 ?

@Jaeyoung-Lim I guess this is the same question as https://github.com/PX4/PX4-user_guide/pull/2094/files#r1008915158 - how do we get it working on real hardware? Do you know of any example/tutorial for real hardware yet?

Wouldn't it be better if all these options were presented as parameters so that you could configure these in the airframe file?

If not, is the suggestion that you do so in an SD card startup file?

[beniaminopozzan]

@hamishwillee precisely. But on real hardware there is also the serial_config parameter like the old micrortps. However, I never tried it yet and it does not allow for specifying custom namespaces.

[hamishwillee]

We might change this back to re-add "without DDS"

[TSC21]

What are the current dev tools needed here other than the ones installed with ROS2? Is ROS2 installation included with the scripts?

[TSC21]

Also we get back to the same situation as before: Are we targeting to use this without or with ROS2 only? If we use ROS2, then FastDDS is installed (then we can either use the micro XRCE-DDS agent or the micro-ROS agent). If we don't install ROS 2, i.e. we want to use DDS exclusively without ROS 2 stuff and so, we use the micro XRCE-DDS agent, then we need to install Fast DDS and its dependencies.

We need to definitely state though how to install and use both micro XRCE-DDS agent and the micro-ROS agent.

[dirksavage88]

@hamishwillee there are multiple ways to get micro-ROS and XRCE-dds:

1. Microxrcedds client + agent built from source: xrcedds install *you can install client and/or agent, as all of these packages are part of a superbuild cmake list, and will install dependencies for you!
2. Standalone microxrce-dds agent via snap install: xrce agent standalone snap
3. Micro-ROS via ros2 colcon build uros ros2 package: * requires running a setup + build script using 'ros2 run' as well as the colcon build tools.
4. micro-ROS via snap package: uros snap

As TSC21 stated, fastdds is still a dependency, but the microxrcedds install from source also call out fastcdr among other packages (foonathon_memory, googletest, spdlog...). However, the SuperBuild.cmake will attempt to find the package, if not found it will clone and build as a dependency. The installation process is very simplified compared to the old docs.

[hamishwillee]

@TSC21"Are we targeting to use this without or with ROS2 only?"

Good question - isn't that up to you to answer? For RTPS docs we did include both cases.

1. My understanding is that both options are supported - right?
2. My further assumption is that the vast majority of users will be accessing via ROS2. If so I suggest that we target these two cases completely separately, and start with instructions that assume ROS2 consumers. Does that make sense?
3. IN that case, what are the simplest instructions we can use to set up fastDDR, microROS and XRCE-dds agent code? My assumption is that it is the stuff in this gist down to the microROS topic - Can you confirm, or is there a better way?

   @dirksavage88 I think this is your option "3" above.

   • Note, @beniaminopozzan says that microROS client is not installed. So presumably this install approach works because microROS dependencies include the XRCE-DDS agent.
4. My understanding is that you don't need to build the microROS or XRCE-DDS modules yourself directly, this just happens as part of the build.
   • is that right?
   • If you don't have FastDDS / ROS installed, does that just mean the module isn't built and included in firmware, but everything else will work?

[hamishwillee]

@beniaminopozzan Re your comment:

Micro ros client is "just" microdds client (the one that PX4 uses) for the low level communication (with the microdds agent) plus the ROS API to have ROS in the device https://micro.ros.org/docs/concepts/client_library/introduction/
the pipeline is something like:
low-resource-device -- microRosClient -- micro XRCE-DDS client ----- micro XRCE-DDS Agent -- microRosAgent -- ROS2

A few follow on questions.

1. I do understand that microROS allows ROS2 on the embedded controller. So it is a ROS2 API layer that connects to the micro XRCE-DDS client.

• Why do you need a microROS agent? When we query our messages from ROS2 in the examples they recognise the ROS2 topics from uORB via XRCE-DDS, so what is the agent doing for us?

Right now, PX4 directly connects to micro XRCE-DDS client.

Yes. But to be precise:
2. Does PX4 support/build the microROSClient in source?
3. Does PX4 include the client in firmware?

Basically I'm trying to understand "what happens next" - my assumption is that if 2 and 3 are "yes" then next step would be for someone to write a ros2 app on PX4, and that they could do that now.

4. Is there a compelling use case for microROS. We generally have been pushing people to companion for years because the FC is resource constrained and harder to write for.

[beniaminopozzan]

I do understand that microROS allows ROS2 on the embedded controller. So it is a ROS2 API layer that connects to the micro XRCE-DDS client.

Yes, I have the same understanding of microROS.

Why do you need a microROS agent?

I really don't know. Having all components under the "ROS2" hat is nice (I mean starting the Agent with ros2 run micro_ros_agent micro_ros_agent) but I guess there is something more, not strictly necessary, some other convenient feature maybe?

Does PX4 support/build the microROSClient in source?
Does PX4 include the client in firmware?

Not right now. Right now only micro XRCE-DDS Client is included in the firmware (in as a submodule of the microdds module).

Basically I'm trying to understand "what happens next"

I can't help you here, let me ping @dagar for these aspects.

[hamishwillee]

What does it mean if ros2 topic list works, but when you try echo one of the displayed topics you get an error?

ubuntu@ubuntu-virtual-machine:~$ ros2 topic echo /fmu/out/vehicle_status
The message type 'px4_msgs/msg/VehicleStatus' is invalid

Note @beniaminopozzan - I used your installation instructions not microROS

EDITED. OK, so if I source humble (source /opt/ros/humble/setup.bash) then ros2 topic list works. TO be able to echo a topic, I need to source the local environment thingy source install/local_setup.bash

Then it works. What's that all about?

Note, further, the tutorial works in this case too.

[beniaminopozzan]

I don't know if this applies anytime that error message appears, but in this case it means that ROS2 doesn't have the message definition for px4_msgs/msg/VehicleStatus (or that the message definition that it has is different from the one used to build that message, I have to check that). Did you not build the package px4_msgs o did you not source the associated environment?

[hamishwillee]

Thanks @beniaminopozzan - I think I'm a slow learner. Got it.

[hamishwillee]

IF we have an installation topic(s), this would be added back or replaced with link to new information.

[TSC21]

FastDDS is still a dependency. Now the important thing here is what I referenced on https://github.com/PX4/PX4-user_guide/pull/2094/files#r1000132738

[hamishwillee]

IF we have an installation topic(s), this would be added back or replaced with link to new information.

[hamishwillee]

Note, rtps mentioned

[TSC21]

this all needs to disappear as per @beniaminopozzan' comment in https://github.com/PX4/PX4-user_guide/pull/2094/files#r1000132554

[hamishwillee]

@akshata-01 FYI I switched this around so this note about fast RTPS is at the bottom. The top should all be interesting info about microDDS. I haven't rewritten that.

[hamishwillee]

Note, deleted content. Not relevant once PR goes in. The note on the microDDS page explains what happened to it and where you go now if you're in old versions

[hamishwillee]

So as noted in SUMMARY.md where I removed the link - we might need a topic like this for microDDS and microROS. IN which case a new one would be created explaining how.

[hamishwillee]

Which uorb topics are available as ROS topics? This used to be done in Yaml. Is it all of them? https://github.com/PX4/PX4-Autopilot/blob/main/msg/CMakeLists.txt#L288

[beniaminopozzan]

@hamishwillee , the uorb topics to expose to ROS2 can be selected editing this https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/microdds_client/dds_topics.yaml

[hamishwillee]

This tutorial stops early. Looking at this more complete one: https://gist.github.com/julianoes/adbf76408663829cd9aed8d14c88fa29#offboard-example-and-px4_msgs

This imports the following:

git clone https://github.com/PX4/px4_msgs.git
git clone https://github.com/PX4/px4_ros_com.git src/px4_ros_com
git clone https://github.com/Jaeyoung-Lim/px4-offboard.git src/px4-offboard

@Jaeyoung-Lim

1. I understand that ROS needs to know what ROS nodes are present, and that these are provided by PX4/px4_msgs - is that right?
2. Presumably the definitions change depending on the build. Does that mean we'll take release snapshots of these.
3. If I build locally, where do the px4_msgs get generated? Or to put it another way, if I create a custom build of PX4, how do I expose messages to my ROS setup?
4. These look just like normal uorb topic definitions - how do they get turned into something your script/ROS can use?
5. I thought that px4_ros_com was no longer needed? Why does that get imported?

[hamishwillee]

Actually, thinking about this, my guess is that you need PX4/px4_msgs if working with XRCE-DDS "alone" in order to tell the toolchain how to build the ROS topics. I assume that the colcon build builds everything, and somewhere in the definitions there is info to tell it to build the ROS2 topics from the messages.

I don't think you need the px4_ros_com at all, ever. If I'm wrong, when is it useful?

So how is microROS different? My guess based on the presentation is that you don't need px4_msgs either. I think in this case the client sends ROS messages by default so there is no need to do any conversion later on. Is that correct? IF not, can you clarify the "usage" difference?

[beniaminopozzan]

PX4/px4_msgs is still needed regardless which "agent", bare XRCE-DDS or microROS, you use. Currently it provides the message definitions to ROS2 (you can try running either agents without this package sourced, no error will appear until you actually try to echo a topic, then ROS2 will complain about the missing message definition). I don't know if in the future this will change, like it will be possible to compile the messages directly from the PX4 main repo.

The best part about this new system is that the message definitions on the PX4 side and the ROS2 side are the same. Therefore you only need a copy-paste of all the .msg files from PX4 to ROS2 to keep the two in synchronized.

px4_ros_com as you said is no more needed. It contains a few examples of nodes and a library to transform frames between ROS2 and PX4 conventions, but it is no more a dependency.

According to the official repo https://github.com/micro-ROS/micro-ROS-Agent, microROS agent is just a ROS2 node that wraps the micro XRCE-DDS Agent. So the communication is always between micro XRCE-DDS Agent and micro XRCE-DDS Client. The agent then exposes the topics to ROS2 .

[ViniciusAbrao]

I have learned a lot in this pull request. While we do not have a official documentation, the @Jaeyoung-Lim ' s offboard package has given I huge documentation. I have recorded a video trying the package in the Foxy version of ROS2. All is working as expected. I would like to share with you in case it can help somehow: https://youtu.be/f5qEXDTZOug

[hamishwillee]

@ViniciusAbrao Thanks for taking the time to post that - I've just skipped through it but looks cool - certainly useful for anyone coming to this PR.

This PR is superseded by another one #2259 . This uses XRCE-DDS agent rather than microROS as for Jae's tutorial.

There are a couple of things that are not obvious from this current PR and from Jae's examples:

1. You can just use XRCE-DDS - you don't need microROS. That's only needed if you have ROS nodes written in PX4 itself (not yet used). The microROS client provides libraries to allow that. Not clear what the agent does "over and above" XRCE-DDS Agent - no one seems to know.
2. The px4_ros_com package isn't needed (at all)
3. Mismatched qos settings in a subscriber can stop you subscribing. [still getting my head around this].

When the docs are done, would love another video from you working through the XRCE-DDS tutorial.

[ViniciusAbrao]

@hamishwillee thank you for your feedback. I got all your points but I have thinking about some points in the future that might have relation with what you said. For example:

1- I could see that the XRCE-DDS implemented in the modules is currently responsible for the ROS topics, but not yet for the ROS services.

2- Looking into the eProsima tutorials: https://micro-xrce-dds.docs.eprosima.com/en/latest/client.html
I did not find yet how to implement ROS services.

3- Looking into the microROS tutorials: https://micro.ros.org/docs/tutorials/programming_rcl_rclc/service/
There is some documentation about how to start doing it.

So at this point, I think that microROS also must be in the PX4 side, in order to simplify the implementations from the client side. If not, going directly through XRCE-DDS would be harder. Does it make sense?

[hamishwillee]

So at this point, I think that microROS also must be in the PX4 side, in order to simplify the implementations from the client side. If not, going directly through XRCE-DDS would be harder. Does it make sense?

Does not make sense sorry unless the summary is "until microROS is being used in PX4 we can't really talk about microROS yet".

The thing to note is that XRCE-DDS is used by microROS. microROS is a layer of libraries that let you do "native" ROS nodes on PX4 rather than uORB, and translating to DDS. What actually gets sent should be pretty much the same, which is why you can use either the XRCE-DDS or microROS agent on the companion to read the topics from PX4.

I don't see to much benefit in talking aobut microROS right now since PX4 doesn't implement/include the microROS client yet. YOu can use the microROS agent or the XRCE-DDS agent on the companion, but I'd rather talk about the XRCE-DDS agent for now - at least until someone explains what value it adds.

[ViniciusAbrao]

Yes, I agree with all your comment. The only thing I am highlighting is the need of the microROS in the PX4. Otherwise I can not see how to implement Services like were done in the past by MAVROS (set_mode to arm, take off, land ... Mission pull/push ). I might be confused at this point, but I did not find yet how to do it directly in the XRCE-DDS, without the layer of libraries provided by microROS.

If I am wrong, I suggest that the documentation presents how to do it in general:

• How to write topics, services, custom msgs, and so on, directly in the XRCE-DDS client.

[mrpollo]

Hey @hamishwillee, hopefully this video by @DanMesh helps with some of the concepts https://youtu.be/CiajtefNQvE

[ViniciusAbrao]

@hamishwillee if I may complement my last comment, I think one question that guide my point of view is:

Is the documentation only for users in the agent side?

In case of the answer is yes, ok. The documentation does not need to talk about microROS.

In case of the answer is NO: How the PX4's user is going to implement ROS services (for example) without microROS in the client?

[hamishwillee]

Yes, I agree with all your comment. The only thing I am highlighting is the need of the microROS in the PX4. Otherwise I can not see how to implement Services like were done in the past by MAVROS (arm, set_mode, take off, land ... ). I might be confused at this point, but I did not find yet how to do it directly in the XRCE-DDS, without the layer of libraries provided by microROS.

If I am wrong, I suggest that the documentation presents how to do it in general:

How to write topics, services, custom msgs, and so on, directly in the XRCE-DDS client.

So MAVROS wraps MAVLink - i.e. it turns a ROS command into a MAVLink command. That MAVLink command is turned into NAV commands and uorb topics and PX4-side stuff.
If you have XRCE-DDS you can publish to uorb topics from ROS. So if everything you need to do in PX4 to takeoff (say) can be represented by uorb topics then you can do that using ROS on the companion side. However if you need access to something on PX4 that is not represented in uORB (or just uORB) then yes, a PX4-side ROS node be needed.

So 2 points:

• I don't know how all those operations are implemented in PX4 or if there are companion side nodes already written to do this without mavros. I suspect that most of them can be done with uorb -e.g. by publishing to http://docs.px4.io/main/en/msg_docs/action_request.html and http://docs.px4.io/main/en/msg_docs/vehicle_command.html
• Docs will cover using ROS to interface in general, but I think you make a very good point that there are standard things you might want to do such as takeoff, and these should be documented.

@beniaminopozzan what's the story with standard libraries in ROS2 for doing stuff like takeoff, arm, etc?

[hamishwillee]

@ViniciusAbrao

Is the documentation only for users in the agent side?

YES. Right now.

Until PX4 starts using it client-side it is too early for docs.

How the PX4's user is going to implement ROS services (for example) without microROS in the client?

See my last answer ^^^. Most of them are likely to be implementable by posting to existing uorb topics. I actually don't know of a use case that needs microROS yet.

[hamishwillee]

Hey @hamishwillee, hopefully this video by @DanMesh helps with some of the concepts https://youtu.be/CiajtefNQvE

Thanks @mrpollo. Nothing I didn't know about ROS, but it does explain some of the work Beat is doing around flight modes in MAVLink and PX4.

[ViniciusAbrao]

@ViniciusAbrao

Is the documentation only for users in the agent side?

YES. Right now.

Until PX4 starts using it client-side it is too early for docs.

How the PX4's user is going to implement ROS services (for example) without microROS in the client?

See my last answer ^^^. Most of them are likely to be implementable by posting to existing uorb topics. I actually don't know of a use case that needs microROS yet.

@hamishwillee

With "ros2 topic list" we can see the topics implemented by the client, and we only have access to them. In the XRCE_DDS client module of PX4 we can see that implementation.

With "ros2 service list" there is not any of that services required to Mission PULL/PUSH, arm, change ....

In the @Jaeyoung-Lim tutorial, He did all that directly in the QGroundControl, and after the drone is on the flight, turned to offboard (also in QGroundControl) and so the ROS node is able to act.

I am trying to see how to implement all that stuffs. If directly in the Agent side, perfect, I do not need to change the firmware (as expected). However, even in this case, the implementation in the agent side probably will be done with microROS (looks like I am a supporter of it ), because, otherwise, I think posting to existing uorb topics without microROS should be harder.

Sorry for extend my comment. It has been done only to clarify.

[beniaminopozzan]

@hamishwillee

what's the story with standard libraries in ROS2 for doing stuff like takeoff, arm, etc?

I'm not really sure what you mean with that. At the best of my knowledge there are no such libraries. You have to manually create a publisher to vehicle_command and send the right message to takeoff, arm, ecc . I just checked PX4/px4_ros_com#179 and it has everything to get a good idea of the required steps to go into offboard, arm, takeoff, land, all without even opening QGC. @ViniciusAbrao this should be useful for you too.
OH, NO microROS at all in this setup.

I think posting to existing uorb topics without microROS should be harder.

It is not trivial but neither impossible IMO.

[ViniciusAbrao]

@hamishwillee

what's the story with standard libraries in ROS2 for doing stuff like takeoff, arm, etc?

I'm not really sure what you mean with that. At the best of my knowledge there are no such libraries. You have to manually create a publisher to vehicle_command and send the right message to takeoff, arm, ecc . I just checked PX4/px4_ros_com#179 and it has everything to get a good idea of the required steps to go into offboard, arm, takeoff, land, all without even opening QGC. @ViniciusAbrao this should be useful for you too. OH, NO microROS at all in this setup.

I think posting to existing uorb topics without microROS should be harder.

It is not trivial but neither impossible IMO.

@beniaminopozzan I could not find a mention to the Mission PULL/PUSH, which were ROS Services in the past with MAVROS. Do you have some suggestion?

[beniaminopozzan]

@ViniciusAbrao oh there is no support for those features yet.

[ViniciusAbrao]

@ViniciusAbrao oh there is no support for those features yet.

@beniaminopozzan

I see ... that is the point. Should not be necessary the microROS in the client side in order to implement ROS Services? Otherwise, looks like it is not possible to do it directly with eProsima Micro XRCE-DDS Client.

[hamishwillee]

@ViniciusAbrao oh there is no support for those features yet.

@beniaminopozzan

I see ... that is the point. Should not be necessary the microROS in the client side in order to implement ROS Services? Otherwise, looks like it is not possible to do it directly with eProsima Micro XRCE-DDS Client.

I don't know what these push/pull things do, but I'd argue that you do not require the microROS client for this. It might make thing easier to write as a ROS node on the device, or it might not. This could be done as a PX4 module that is triggered from an external ROS node via uORB.

Before you started you'd want to look at the requirement: it might make sense to do it somehow by file sharing.

[ViniciusAbrao]

@ViniciusAbrao oh there is no support for those features yet.

@beniaminopozzan
I see ... that is the point. Should not be necessary the microROS in the client side in order to implement ROS Services? Otherwise, looks like it is not possible to do it directly with eProsima Micro XRCE-DDS Client.

I don't know what these push/pull things do, but I'd argue that you do not require the microROS client for this. It might make thing easier to write as a ROS node on the device, or it might not. This could be done as a PX4 module that is triggered from an external ROS node via uORB.

Before you started you'd want to look at the requirement: it might make sense to do it somehow by file sharing.

@hamishwillee The push/pull are responsible for include/exclude points in the mission during the flight. This is very common when whe are working in the Mission Mode, when we previously the flight define the points where the drone needs to pass.

@beniaminopozzan If both the ROS service server and ROS service client are in the agent side of the bridge, that is ok.... But I can imagine that for some security reason, or maybe in a scenario with more than one agent, the ROS service server (this is unique) should be in the Client side of the bridge, and the ROS service client would be in the Agents of the bridge (more than one if necessary in case of, for example, both companion computer and ground station computer).

[ViniciusAbrao]

@hamishwillee

what's the story with standard libraries in ROS2 for doing stuff like takeoff, arm, etc?

I'm not really sure what you mean with that. At the best of my knowledge there are no such libraries. You have to manually create a publisher to vehicle_command and send the right message to takeoff, arm, ecc . I just checked PX4/px4_ros_com#179 and it has everything to get a good idea of the required steps to go into offboard, arm, takeoff, land, all without even opening QGC. @ViniciusAbrao this should be useful for you too. OH, NO microROS at all in this setup.

I think posting to existing uorb topics without microROS should be harder.

It is not trivial but neither impossible IMO.

I have translated the code to Python including: arm, take off, offboard flight and land:

https://github.com/ViniciusAbrao/px4_ros2_xrcedds/blob/master/offboard_control.py

[mrpollo]

Hey everyone, I appreciate the help testing the PR. However, let's keep this comment thread about the changeset and start filing support issues here PX4/PX4-Autopilot#21120

This will help us focus on getting this PR through the finish line.

[hamishwillee]

@ViniciusAbrao Re "Working with real hardware (pixhawk 6C), looks like the client is not automatically started... " - correct, that is covered in the PR that replaces this. You would normally have a line that starts it in system startup for the particular channel you're using - probably from an SD card start file. That channel will be different than the one used for mavlink unless you invent a protocol splitter (Auterion have one, but not sure it is open sourced)

[hamishwillee]

I am closing this as most of the work has now been done elsewhere, and this has been data mined. Thank you @akshata-01 for taking the lead on this to get it kicked off.

[mrpollo]

Thank you @akshata-01 🎉