Skip to content
Closed
Binary file added assets/middleware/microdds/simulation.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added assets/middleware/microdds/topic.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
6 changes: 2 additions & 4 deletions en/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -313,7 +313,6 @@
* [Ubuntu Setup](dev_setup/dev_env_linux_ubuntu.md)
* [Windows Setup](dev_setup/dev_env_windows_wsl.md)
* [Visual Studio Code IDE](dev_setup/vscode.md)
* [Fast DDS installation](dev_setup/fast-dds-installation.md)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* [Building the Code](dev_setup/building_px4.md)
* [Writing your First Application](modules/hello_sky.md)
* [Application/Module Template](modules/module_template.md)
Expand Down Expand Up @@ -538,8 +537,7 @@
* [wind](msg_docs/wind.md)
* [yaw_estimator_status](msg_docs/yaw_estimator_status.md)
* [MAVLink Messaging](middleware/mavlink.md)
* [RTPS/DDS Interface: PX4-Fast RTPS(DDS) Bridge](middleware/micrortps.md)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

* [Manually Generate Client/Agent](middleware/micrortps_manual_code_generation.md)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we don't need this anymore

* [MicroDDS PX4-Bridge](middleware/microdds.md)
* [Modules & Commands](modules/modules_main.md)
* [Commands](modules/modules_command.md)
* [Communication](modules/modules_communication.md)
Expand Down Expand Up @@ -611,7 +609,7 @@
* [ROS](ros/README.md)
* [ROS 2](ros/ros2.md)
* [ROS 2 User Guide](ros/ros2_comm.md)
* [ROS 2 microRTPS Offboard Control Example](ros/ros2_offboard_control.md)
* [ROS 2 microRTPS Offboard Control Example](ros/ros2_offboard_control.md)
Copy link
Copy Markdown
Collaborator

@hamishwillee hamishwillee Oct 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

* [ROS (1) via ROS 2 Bridge](ros/ros1_via_ros2.md)
* [ROS (1) with MAVROS](ros/ros1.md)
* [ROS/MAVROS Installation Guide](ros/mavros_installation.md)
Expand Down
8 changes: 4 additions & 4 deletions en/advanced_config/ethernet_setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -203,10 +203,10 @@ However this is not recommended because the default configuration is optimised f


## ROS2 Setup Example

Prerequisites:

- You have a supported autopilot hardware with RTPS feature enabled firmware on it by using [this guide](../middleware/micrortps.md#client-px4-px4-autopilot).
Copy link
Copy Markdown
Collaborator

@hamishwillee hamishwillee Oct 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Prerequisites:
- You have a supported autopilot hardware with RTPS feature enabled firmware on it by using [this guide](../middleware/micrortps.md#client-px4-px4-autopilot).
- [ROS2](../ros/ros2_comm.md#sanity-check-the-installation) has been set up correctly and [sanity check](../ros/ros2_comm.md#sanity-check-the-installation) has been confirmed.
- You have followed the Ethernet network and port setup as discussed at the top of this page.

Expand Down
2 changes: 1 addition & 1 deletion en/dev_setup/building_px4.md
Original file line number Diff line number Diff line change
Expand Up @@ -256,7 +256,7 @@ make [VENDOR_][MODEL][_VARIANT] [VIEWER_MODEL_DEBUGGER_WORLD]
- **VENDOR:** The manufacturer of the board: `px4`, `aerotenna`, `airmind`, `atlflight`, `auav`, `beaglebone`, `intel`, `nxp`, etc.
The vendor name for Pixhawk series boards is `px4`.
- **MODEL:** The *board model* "model": `sitl`, `fmu-v2`, `fmu-v3`, `fmu-v4`, `fmu-v5`, `navio2`, etc.
- **VARIANT:** Indicates particular configurations: e.g. `rtps`, `lpe`, which contain components that are not present in the `default` configuration. Most commonly this is `default`, and may be omitted.
- **VARIANT:** Indicates particular configurations: e.g. `rtps`, `lpe`, which contain components that are not present in the `default` configuration. Most commonly this is `default`, and may be omitted.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What @beniaminopozzan said

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.


:::tip
You can get a list of *all* available `CONFIGURATION_TARGET` options using the command below:
Expand Down
2 changes: 1 addition & 1 deletion en/dev_setup/dev_env_linux_arch.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ See [Toolchain Installation](../dev_setup/dev_env.md) for information about the

The PX4-Autopilot repository provides a convenient script to set your Arch installation up for PX4 development: [Tools/setup/arch.sh](https://github.com/PX4/PX4-Autopilot/blob/main/Tools/setup/arch.sh). <!-- NEED px4_version -->

The script installs (by default) all tools to build PX4 (without RTPS) for NuttX targets and run simulation with *jMAVsim*.
The script installs (by default) all tools to build PX4 for NuttX targets and run simulation with *jMAVsim*.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Collaborator

@hamishwillee hamishwillee Jan 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

  1. 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.

Copy link
Copy Markdown
Member

@beniaminopozzan beniaminopozzan Feb 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@hamishwillee hamishwillee Feb 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

You can additionally install the *Gazebo* simulator by specifying the command line argument: `--gazebo`.

![Gazebo on Arch](../../assets/simulation/gazebo/arch-gazebo.png)
Expand Down
10 changes: 0 additions & 10 deletions en/dev_setup/dev_env_linux_ubuntu.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,6 @@ This environment can be used to build PX4 for [most PX4 targets](../dev_setup/de
* [Gazebo Simulation](../simulation/gazebo.md)
* [Raspberry Pi](#raspberry-pi)
* [ROS (1)](#ros-gazebo) (Robotics Operating System)
* [Fast DDS](../dev_setup/fast-dds-installation.md) - Required for ROS2
Copy link
Copy Markdown
Collaborator

@hamishwillee hamishwillee Oct 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


:::tip
This setup is supported by the PX4 dev team.
Expand Down Expand Up @@ -207,15 +206,6 @@ To install the development toolchain:
:::


<a id="fast_dds"></a>
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<a id="fast_rtps"></a>
## Fast DDS installation

[eProsima Fast DDS](https://github.com/eProsima/Fast-DDS) is required if you're using PX4 with ROS2 (or some other RTPS/DDS system).

Follow the instructions in [Fast DDS Installation](../dev_setup/fast-dds-installation.md) to install it.


## Next Steps

Once you have finished setting up the command-line toolchain:
Expand Down
148 changes: 0 additions & 148 deletions en/dev_setup/fast-dds-installation.md

This file was deleted.

2 changes: 1 addition & 1 deletion en/hardware/porting_guide_config.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ Builds will silently ignore any missing or miss-spelled modules in the `*.px4bo
Each PX4 board must have a `default.px4board` configuration and can have an optional `bootloader.px4board configuration`.
However you can add also separate configurations under a different label e.g. `rtps.px4board`.
Note that by default the configuration of `rtps.px4board` inherits all settings set in `default.px4board`.
When changing the `rtps.px4board` it only stores the delta of the Kconfig keys that are different compared to `default.px4board`, this is useful to simplify configurations management
When changing the `rtps.px4board` it only stores the delta of the Kconfig keys that are different compared to `default.px4board`, this is useful to simplify configurations management.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, rtps mentioned

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


:::note
When modifying a Kconfig key in `default.px4board` it will be modified in all derivative configurations of the same board that had the same config as well.
Expand Down
74 changes: 74 additions & 0 deletions en/middleware/microdds.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
# MicroDDS
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Micro DDS" was the name given to the PX4 Module that handles the uORB translation to-from the DDS data space. What's the end goal of this document though? Is it talking about how we are bridging PX4 with ROS 2 / DDS, or talk about Micro XRCE-DDS? I recall that Micro XRCE-DDS is a software component built by eProsima that leverages the DDS-XRCE protocol (maybe worth making a mention to that). What we are doing in the end is just leveraging their XRCE-DDS implementation on both sides of the serial/UDP/TCP link - in one side we use the Micro XRCE-DDS client libraries on the PX4 microdds module, and in the other side we use their own maintained agents (either Micro XRCE-DDS Agent or the Micro-ROS agent). We need to make sure that's what is reflected on this document.


Micro XRCE-DDS is a software solution that enables communication with an existing DDS network.

The new approach provides a faster and simpler method of integrating applictaions running and linked in DDS domains (including ROS nodes), making it easy to share sensor data, commands, and other vehicle information.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New in comparison to what? What are we trying to compare this against? micro-RTPS? If yes, please remove this - we removed micro-RTPS and the document should only reflect the usage of Micro XRCE-DDS (client library and agent).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, @akshata-01 please rewrite this sentence "This interface allows for a fast and simple method of..." no need to compare against what is no longer available


The following guide describes the new PX4 bridge architecture, and shows the reader how to write a simple *Micro DDS* application to subscribe * publish telemetry updates from the PX4 Autopilot.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, do not use "new" - let's say it's just the bridge that is supported.

And should be "PX4-ROS2 bridge"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no Micro DDS application - there's an application that interfaces with the DDS data space by advertising itself and publishing/subscribing to data on the DDS network, and so when you write an application, you are trying to interface with other participants on that data space.


:::note
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

MicroDDS has replaced the PX4 FastRTPS (DDS) Bridge.
If you're working PX4 v1.13 (or earlier) FastRTPS documentation can be found here:

- [RTPS/DDS Interface: PX4-Fast RTPS(DDS) Bridge](https://docs.px4.io/v1.13/en/middleware/micrortps.html)
- [Manually Generate Client and Agent Code](https://docs.px4.io/v1.13/en/middleware/micrortps_manual_code_generation.html)
- [Fast DDS Installation](https://docs.px4.io/v1.13/en/dev_setup/fast-dds-installation.html)
:::


## Why this approach is of interest?

Initially, micro-RTPS served as the middleware and its consistent improvement evolved into what's known as the microDDS that provides the user a native interface between the flight controller and the mission computer DDS/ROS2 data space.
The notable difference between the two is what kind of transport protocol each supports. The newest version supports UDP/TCP/Serial/Custom transport protocol.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little short as in terms of differences between each - please check my presentation with Pablo from eProsima one this topic: https://github.com/PX4/PX4-user_guide/pull/2094/files#r1000132554. Probably making a reference to the video instead would help.


The Micro-XRCE-DDS-Gen has 2 major advantages, i.e. it can be used to generate client code and build px4_msgs along with microdds_client together creating a single library.

:::tip

:::

## Architectural overview

### microDDS Bridge

[*micro XRCE-DDS*](https://micro-xrce-dds.docs.eprosima.com/en/stable/introduction.html) provides a DDS publisher/subscriber middleware wherein the client is on a low-resource consumption device and the agent is connected to with the DDS global data space.

#### The microdds Client
The *Client* is the PX4 Autopilot middleware daemon process that runs on the flight controller. The client can either publish or subcribe directly to data topics because the agent itself acts on behalf of the [client](https://micro-xrce-dds.docs.eprosima.com/en/stable/client.html)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The *Client* is the PX4 Autopilot middleware daemon process that runs on the flight controller. The client can either publish or subcribe directly to data topics because the agent itself acts on behalf of the [client](https://micro-xrce-dds.docs.eprosima.com/en/stable/client.html)
The *Client* (`microdds_client`) is the PX4 Autopilot middleware daemon process that runs on the flight controller. The client can either publish or subscribe directly to data topics because the agent itself acts on behalf of the [client](https://micro-xrce-dds.docs.eprosima.com/en/stable/client.html). The client is also responsible from translation uORB topic data to data on the DDS dataspace.


#### The microdds Agent
The *Agent* runs as a daemon process that's defined by what the clients defines it to be and hence it's dynamic. It's a server that acts an an intermediary between the client and the DDS Global Data Space.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The language is a bit confusing here. @hamishwillee do you have a suggestion on how we can make it a bit more explicit?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could, but I will probably re-write most of this based on your presentation once I understand how it works.


#### microdds Communication
microDDS has APIs that allow writing time-critical applications and can be used over many transport protocols supporting TCP,UDP over Ethernet Wi-Fi & 6LoWPAN and Bluetooth. The user can also customise this making microDDS transport-agnostic.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

microDDS doesn't have an API. Micro XRCE-DDS does provide a library that contains an API that we consume on the microDDS module in PX4 (and of course on Micro XRCE-DDS agent). So you have a client library and an agent library (maybe reasonable to point where this is on the eProsima docs).


## Test

Let’s test!
You can check the microdds running using a grep command (ps aux | grep micro)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is specifically for a SITL instance. Are there plans to show how this can be tested on real hardware?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sub this as well.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to have those docs

Can you help me create one? any direction you can provide will help me create something


TERMINAL 1
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really a fan of terminal 1 / terminal 2 -> Could we change this to more informative descriptions on what we are running exactly?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, TERMINAL 1 vs 2 is the wrong way of doing this.

I'll review and update


Start your favorite simulation model, we’re gonna go with the default.

```sh
cd ~/PX4_Autopilot #Into your Autopilot folder
make px4_sitl gazebo
```
Gazebo must open and you can check the micro-dds client running with the following command

```sh
microdds_client status #Checks client status
```
![Simulation](../../assets/middleware/microdds/simulation.png)

TERMINAL 2

```sh
cd ~/px4_ros2_ws #Intro your ROS2 directory
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example is just doing a ros2 topic echo. Therefore a ros2 workspace is not necessary

source /opt/ros/humble/setup.bash
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that this document is assuming that you are running ros2 humble. The current default supported Ubuntu distribution of PX4 is Ubuntu 20.04, and this supports ROS Foxy.

ROS Humble only supports Ubuntu 22.04, which PX4 doesn't fully support yet. therefore, I think we need to set the current ros2 support to ROS foxy at least for now

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sub this!

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plan is to upgrade PX4 to Ubuntu 22.04 as well. (correct me if I'm wrong @dagar)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TSC21 @mrpollo So we're now in Jan 2022 - my assumption is that ROS2 humble is the target, and that this is on Ubuntu 22.04. Or at least that is what I will try out.

  • Has PX4 been validated/updated to Ubuntu 22.04? Is there an ETA or a plan for this?

source install/setup.bash
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
source install/setup.bash
source install/local_setup.bash

Copy link
Copy Markdown
Contributor

@dirksavage88 dirksavage88 Oct 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually local setup is sourced if you have just the ros2 workspace and don't need to rely on parent packages installed elsewhere. However, I'm imaging users running an overlay with their own custom/modified packages but also needing to source the underlay.

source: Configuring environment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dirksavage88 exactly

ros2 topic list -v #Displays available topic
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ros2 topic echo fmu/out/vehicle_status #You can check any available topic
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would require the user installing and setting up ros2. Shouldn't this be explained more on how ros2 could be setup, or at least link the docs?

```
![ROS2 Topic](../../assets/middleware/microdds/topic.png)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 .

Loading