PX4 오토파일럿 사용자 설명서

# ROS 2 User Guide

The ROS 2-PX4 architecture provides a deep integration between ROS 2 and PX4, allowing ROS 2 subscribers or publisher nodes to interface directly with PX4 uORB topics.

This topic provides an overview of the architecture and application pipeline, and explains how to setup and use ROS 2 with PX4.

# 개요

The application pipeline for ROS 2 is very straightforward, thanks to the use of the XRCE-DDS communications middleware.

Architecture XRCE-DDS with ROS 2

The XRCE-DDS middleware consists of a client running on PX4 and an agent running on the companion computer, with bi-directional data exchange between them over a serial, UDP, TCP or custom link. The agent acts as a proxy for the client to publish and subscribe to topics in the global DDS data space.

The PX4 microdds-client is generated at build time and included in PX4 firmare by default. It includes both the "generic" XRCE-DDS client code, and PX4-specific translation code that it uses to publish to/from uORB topics. The subset of uORB messages that are generated into the client are listed in PX4-Autopilot/src/modules/microdds_client/dds_topics.yaml (opens new window). The generator uses the uORB message definitions in the source tree: PX4-Autopilot/msg (opens new window) to create the code for sending ROS 2 messages.

ROS 2 applications need to be built in a workspace that has the same message definitions that were used to create the XRCE-DDS client module in the PX4 Firmware. You can include these by cloning the PX4/px4_msgs (opens new window) into your ROS 2 workspace (branches in the repo correspond to the messages for different PX4 releases).

Note that the XRCE-DDS agent itself has no dependency on client-side code. It can be built from source (opens new window) either standalone or as part of a ROS build, or installed as a snap.

You will normally need to start both the client and agent when using ROS 2. Note that the XRCE-DDS client is built into firmware by default but not started automatically except for simulator builds.

Note

In PX4v1.13 and earlier, ROS 2 was dependent on definitions in px4_ros_com (opens new window). This repo is no longer needed, but does contain useful examples.

# 설치 및 설정

The supported platform for PX4 development is Ubuntu 20.04 (at time of writing), which means that you should use ROS 2 "Foxy".

WARNING

Other platforms, such as Ubuntu 22.04 and ROS 2 "Humble", may work, but are not fully tested and officially supported by the PX4 dev team.

To setup ROS 2 for use with PX4 you will need to:

Other dependencies of the architecture that are installed automatically, such as Fast DDS, are not covered.

# Install PX4

You need to install the PX4 development toolchain in order to use the simulator.

Note

The only dependency ROS 2 has on PX4 is the set of message definitions, which it gets from px4_msgs (opens new window). You only need to install PX4 if you need the simulator (as we do in this guide), or if you are creating a build that publishes custom uORB topics.

Set up a PX4 development environment on Ubuntu in the normal way:

  1. Setup the development environment for Ubuntu
  2. Download PX4 source

# ROS2 설치

To install ROS 2 and its dependencies:

  1. Install ROS 2 Foxy (opens new window)

    • You can install either the desktop (ros-foxy-desktop) or bare-bones (ros-foxy-ros-base) version
    • You should additionally install the development tools (ros-dev-tools)

  2. Some Python dependencies must also be installed (using pip or apt):

    pip3 install --user -U empy pyros-genmsg setuptools

# Setup XRCE-DDS Agent & Client

For ROS 2 to communicate with PX4, a XRCE-DDS client must be running on PX4, connected to an XRCE-DDS agent running on the companion computer.

# Setup the Agent

The agent can be installed onto the companion computer in a number of ways. Below we show how to build the agent "standalone" from source and connect to a client running on the PX4 simulator.

To setup and start the agent:

  1. Open a terminal.

  2. Enter the following commands to fetch and build the agent from source:

    git clone https://github.com/eProsima/Micro-XRCE-DDS-Agent.git
cd Micro-XRCE-DDS-Agent
mkdir build
cd build
cmake ..
make
sudo make install
sudo ldconfig /usr/local/lib/

  3. Start the agent with settings for connecting to the XRCE-DDS client running on the simulator:

    MicroXRCEAgent udp4 -p 8888

The agent is now running, but you won't see much until we start PX4 (in the next step).

Note

You can leave the agent running in this terminal! Note that only one agent is allowed per connection channel.

# Start the Client

The PX4 simulator starts the XRCE-DDS client automatically, connecting to UDP port 8888 on the local host.

To start the simulator (and client):

  1. Open a new terminal in the root of the PX4 Autopilot repo that was installed above.

  2. Start a PX4 Gazebo Classic simulation using:

    make px4_sitl gazebo-classic

The agent and client are now running they should connect.

The PX4 terminal displays the NuttShell/PX4 System Console output as PX4 boots and runs. As soon as the agent connects the output should include INFO messages showing creation of data writers:

...
INFO  [microdds_client] synchronized with time offset 1675929429203524us
INFO  [microdds_client] successfully created rt/fmu/out/failsafe_flags data writer, topic id: 83
INFO  [microdds_client] successfully created rt/fmu/out/sensor_combined data writer, topic id: 168
INFO  [microdds_client] successfully created rt/fmu/out/timesync_status data writer, topic id: 188
...

The XRCE-DDS agent terminal should also start to show output, as equivalent topics are created in the DDS network:

...
[1675929445.268957] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x00000001, publisher_id: 0x0DA(3), participant_id: 0x001(1)
[1675929445.269521] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x00000001, datawriter_id: 0x0DA(5), publisher_id: 0x0DA(3)
[1675929445.270412] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x00000001, topic_id: 0x0DF(2), participant_id: 0x001(1)
...

# ROS 2 작업 공간 빌드

This section shows how create a ROS 2 workspace hosted in your home directory (modify the commands as needed to put the source code elsewhere).

The px4_ros_com (opens new window) and px4_msgs (opens new window) packages are cloned to a workspace folder, and then the colcon tool is used to build the workspace. The example is run using ros2 launch.

Note

The example builds the ROS 2 Listener example application, located in px4_ros_com (opens new window). px4_msgs (opens new window) is needed too so that the example can interpret PX4 ROS 2 topics.

# Building the Workspace

To create and build the workspace:

  1. Open a new terminal.

  2. Create and navigate into a new workspace directory using:

    mkdir -p ~/ws_sensor_combined/src/
cd ~/ws_sensor_combined/src/

Note

A naming convention for workspace folders can make it easier to manage workspaces. 특히 --verbose 인수는 전체 colcon 빌드 출력을 보여줍니다.

  1. Clone the example repository and px4_msgs (opens new window) to the /src directory (the main branch is cloned by default, which corresponds to the the version of PX4 we are running):

    git clone https://github.com/PX4/px4_msgs.git
git clone https://github.com/PX4/px4_ros_com.git

  2. Source the ROS 2 development environment ("foxy") into the current terminal and compile the workspace using colcon:

    cd ..
source /opt/ros/foxy/setup.bash
colcon build

    This builds all the folders under /src using the "foxy" toolchain.

# Running the Example

To run the executables that you just built, you need to source local_setup.bash. This provides access to the "environment hooks" for the current workspace. In other words, it makes the executables that were just built available in the current terminal.

In the same terminal:

  1. Source the local_setup.bash (you should also source setup.bash if in a new terminal).

    source install/local_setup.bash

  2. Now launch the example. Note here that we use ros2 launch, which is described below.

    ros2 launch px4_ros_com sensor_combined_listener.launch.py

If this is working you should see data being printed on the terminal/console where you launched the ROS listener:

RECEIVED DATA FROM SENSOR COMBINED
================================
ts: 870938190
gyro_rad[0]: 0.00341645
gyro_rad[1]: 0.00626475
gyro_rad[2]: -0.000515705
gyro_integral_dt: 4739
accelerometer_timestamp_relative: 0
accelerometer_m_s2[0]: -0.273381
accelerometer_m_s2[1]: 0.0949186
accelerometer_m_s2[2]: -9.76044
accelerometer_integral_dt: 4739

# Controlling a Vehicle

To control applications, ROS 2 applications:

  • subscribe to (listen to) telemetry topics published by PX4
  • publish to topics that cause PX4 to perform some action.

The topics that you can use are defined in dds_topics.yaml (opens new window), and you can get more information about their data in the uORB Message Reference. For example, VehicleGlobalPosition can be used to get the vehicle global position, while VehicleCommand can be used to command actions such as takeoff and land.

The ROS 2 Example applications examples below provide concrete examples of how to use these topics.

# Compatibility Issues

This section contains information that may affect how you write your ROS code.

# ROS 2 Subscriber QoS Settings

ROS 2 code that subscribes to topics published by PX4 must specify a appropriate (compatible) QoS setting in order to listen to topics. Specifically, nodes should subscribe using the ROS 2 predefined QoS sensor data (from the listener example source code):

...
rmw_qos_profile_t qos_profile = rmw_qos_profile_sensor_data;
auto qos = rclcpp::QoS(rclcpp::QoSInitialization(qos_profile.history, 5), qos_profile);

subscription_ = this->create_subscription<px4_msgs::msg::SensorCombined>("/fmu/out/sensor_combined", qos,
...

This is needed because the ROS 2 default Quality of Service (QoS) settings (opens new window) are different from the settings used by PX4. Not all combinations of publisher-subscriber Qos settings are possible (opens new window), and it turns out that the default ROS 2 settings for subscribing are not! Note that ROS code does not have to set QoS settings when publishing (the PX4 settings are compatible with ROS defaults in this case).

# ROS 2 예제 애플리케이션

# ROS 2 Listener

The ROS 2 listener examples (opens new window) in the px4_ros_com (opens new window) repo demonstrate how to write ROS nodes to listen to topics published by PX4.

Here we consider the sensor_combined_listener.cpp (opens new window) node under px4_ros_com/src/examples/listeners, which subscribes to the SensorCombined message.

Note

Build ROS 2 Workspace shows how to build and run this example.

The code first imports the C++ libraries needed to interface with the ROS 2 middleware and the header file for the SensorCombined message to which the node subscribes:

#include <rclcpp/rclcpp.hpp>
#include <px4_msgs/msg/sensor_combined.hpp>

아래 줄은 하나 이상의 호환 가능한 ROS 게시자와 일치시킬 수 있는 sensor_combined_topic에 대한 구독을 만듭니다.

/**
 * @brief Sensor Combined uORB topic data callback
 */
class SensorCombinedListener : public rclcpp::Node
{

This creates a callback function for when the SensorCombined uORB messages are received (now as XRCE-DDS messages), and outputs the content of the message fields each time the message is received.

public:
    explicit SensorCombinedListener() : Node("sensor_combined_listener")
    {
        rmw_qos_profile_t qos_profile = rmw_qos_profile_sensor_data;
        auto qos = rclcpp::QoS(rclcpp::QoSInitialization(qos_profile.history, 5), qos_profile);

        subscription_ = this->create_subscription<px4_msgs::msg::SensorCombined>("/fmu/out/sensor_combined", qos,
        [this](const px4_msgs::msg::SensorCombined::UniquePtr msg) {
            std::cout << "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n";
            std::cout << "RECEIVED SENSOR COMBINED DATA"   << std::endl;
            std::cout << "============================="   << std::endl;
            std::cout << "ts: "          << msg->timestamp    << std::endl;
            std::cout << "gyro_rad[0]: " << msg->gyro_rad[0]  << std::endl;
            std::cout << "gyro_rad[1]: " << msg->gyro_rad[1]  << std::endl;
            std::cout << "gyro_rad[2]: " << msg->gyro_rad[2]  << std::endl;
            std::cout << "gyro_integral_dt: " << msg->gyro_integral_dt << std::endl;
            std::cout << "accelerometer_timestamp_relative: " << msg->accelerometer_timestamp_relative << std::endl;
            std::cout << "accelerometer_m_s2[0]: " << msg->accelerometer_m_s2[0] << std::endl;
            std::cout << "accelerometer_m_s2[1]: " << msg->accelerometer_m_s2[1] << std::endl;
            std::cout << "accelerometer_m_s2[2]: " << msg->accelerometer_m_s2[2] << std::endl;
            std::cout << "accelerometer_integral_dt: " << msg->accelerometer_integral_dt << std::endl;
        });
    }

Note

The subscription sets a QoS profile based on rmw_qos_profile_sensor_data. This is needed because the default ROS 2 QoS profile for subscribers is incompatible with the PX4 profile for publishers. For more information see: ROS 2 Subscriber QoS Settings,

The lines below create a publisher to the SensorCombined uORB topic, which can be matched with one or more compatible ROS 2 subscribers to the fmu/sensor_combined/out ROS 2 topic.

private:
    rclcpp::Subscription<px4_msgs::msg::SensorCombined>::SharedPtr subscription_;
};

px4_ros_com/src/advertisers 아래의 debug_vect_advertiser.cpp를 예로 들면 먼저 debug_vect msg 헤더를 포함한 필수 헤더를 가져옵니다.

int main(int argc, char *argv[])
{
    std::cout << "Starting sensor_combined listener node..." << std::endl;
    setvbuf(stdout, NULL, _IONBF, BUFSIZ);
    rclcpp::init(argc, argv);
    rclcpp::spin(std::make_shared<SensorCombinedListener>());

    rclcpp::shutdown();
    return 0;
}

This particular example has an associated launch file at launch/sensor_combined_listener.launch.py (opens new window). This allows it to be launched using the ros2 launch command.

# ROS 2 Advertiser

그런 다음 코드는 일반 rclcpp::Node 기본 클래스의 하위 클래스인 DebugVectAdvertiser 클래스를 생성합니다.

Taking as an example the debug_vect_advertiser.cpp under px4_ros_com/src/advertisers, first we import required headers, including the debug_vect msg header.

#include <chrono>
#include <rclcpp/rclcpp.hpp>
#include <px4_msgs/msg/debug_vect.hpp>

DebugVectAdvertiser 클래스를 ROS 노드로 인스턴스화하는 작업은 main 함수에서 수행됩니다.

class DebugVectAdvertiser : public rclcpp::Node
{

The code below creates a function for when messages are to be sent. The messages are sent based on a timed callback, which sends two messages per second based on a timer.

public:
    DebugVectAdvertiser() : Node("debug_vect_advertiser") {
        publisher_ = this->create_publisher<px4_msgs::msg::DebugVect>("DebugVect_PubSubTopic", 10);
        auto timer_callback =
        [this]()->void {
            auto debug_vect = px4_msgs::msg::DebugVect();
            debug_vect.timestamp = std::chrono::time_point_cast<std::chrono::microseconds>(std::chrono::steady_clock::now()).time_since_epoch().count();
            std::string name = "test";
            std::copy(name.begin(), name.end(), debug_vect.name.begin());
            debug_vect.x = 1.0;
            debug_vect.y = 2.0;
            debug_vect.z = 3.0;
            RCLCPP_INFO(this->get_logger(), "\033[97m Publishing debug_vect: time: %llu x: %f y: %f z: %f \033[0m",
                                debug_vect.timestamp, debug_vect.x, debug_vect.y, debug_vect.z);
            this->publisher_->publish(debug_vect);
        };
        timer_ = this->create_wall_timer(500ms, timer_callback);
    }

private:
    rclcpp::TimerBase::SharedPtr timer_;
    rclcpp::Publisher<px4_msgs::msg::DebugVect>::SharedPtr publisher_;
};

The instantiation of the DebugVectAdvertiser class as a ROS node is done on the main function.

int main(int argc, char *argv[])
{
    std::cout << "Starting debug_vect advertiser node..." << std::endl;
    setvbuf(stdout, NULL, _IONBF, BUFSIZ);
    rclcpp::init(argc, argv);
    rclcpp::spin(std::make_shared<DebugVectAdvertiser>());

    rclcpp::shutdown();
    return 0;
}

# 오프보드 제어

For a complete reference example on how to use Offboard control with PX4, see: ROS 2 Offboard control example.

# Using Flight Controller Hardware

ROS 2 with PX4 running on a flight controller is almost the same as working with PX4 on the simulator. The only difference is that you need to start both the agent and the client, with settings appropriate for the communication channel.

For more information see Starting XRCE-DDS.

# Custom uORB Topics

ROS 2 needs to have the same message definitions that were used to create the XRCE-DDS client module in the PX4 Firmware. These are automatically exported to PX4/px4_msgs (opens new window) for main and release builds, and you can just clone them into your workspace.

If working on a custom build that has other messages, you would:

  • Update the dds_topics.yaml (opens new window) to add needed topics to the XRCE-DDS client in your PX4 firmware.
  • Copy the msg definitions out of the PX4 source tree into any ROS 2 workspace that needs them. The messages must be in a folder named px4_msgs/msg/.

Note

Technically the messages must be in a folder defined by the type prefix in the yaml file: As you can see below, this is px4_msgs::msg:::

- topic: /fmu/out/vehicle_odometry
  type: px4_msgs::msg::VehicleOdometry

# ros2 CLI

The ros2 CLI (opens new window) is a useful tool for working with ROS. You can use it, for example, to quickly check whether topics are being published, and also inspect them in detail if you have px4_msg in the workspace. The command also lets you launch more complex ROS systems via a launch file. A few possibilities are demonstrated below.

# ros2 topic list

Use ros2 topic list to list the topics visible to ROS 2:

ros2 topic list

If PX4 is connected to the agent, the result will be a list of topic types:

/fmu/in/obstacle_distance
/fmu/in/offboard_control_mode
/fmu/in/onboard_computer_status
...

Note that the workspace does not need to build with px4_msgs for this to succeed; topic type information is part of the message payload.

# ros2 topic echo

Use ros2 topic echo to show the details of a particular topic.

Unlike with ros2 topic list, for this to work you must be in a workspace has built the px4_msgs and sourced local_setup.bash so that ROS can interpret the messages.

ros2 topic echo /fmu/out/vehicle_status

The command will echo the topic details as they update.

---
timestamp: 1675931593364359
armed_time: 0
takeoff_time: 0
arming_state: 1
latest_arming_reason: 0
latest_disarming_reason: 0
nav_state_timestamp: 3296000
nav_state_user_intention: 4
nav_state: 4
failure_detector_status: 0
hil_state: 0
...
---

# ros2 topic hz

You can get statistics about the rates of messages using ros2 topic hz. For example, to get the rates for SensorCombined:

ros2 topic hz /fmu/out/sensor_combined

The output will look something like:

average rate: 248.187
  min: 0.000s max: 0.012s std dev: 0.00147s window: 2724
average rate: 248.006
  min: 0.000s max: 0.012s std dev: 0.00147s window: 2972
average rate: 247.330
  min: 0.000s max: 0.012s std dev: 0.00148s window: 3212
average rate: 247.497
  min: 0.000s max: 0.012s std dev: 0.00149s window: 3464
average rate: 247.458
  min: 0.000s max: 0.012s std dev: 0.00149s window: 3712
average rate: 247.485
  min: 0.000s max: 0.012s std dev: 0.00148s window: 3960

# ros2 launch

The ros2 launch command is used to start a ROS 2 launch file. For example, above we used ros2 launch px4_ros_com sensor_combined_listener.launch.py to start the listener example.

You don't need to have a launch file, but they are very useful if you have a complex ROS 2 system that needs to start several components.

For information about launch files see ROS 2 Tutorials > Creating launch files (opens new window)

# Troubleshooting

# Missing dependencies

The standard installation should include all the tools needed by ROS 2.

If any are missing, they can be added separately:

  • colcon build tools should be in the development tools. It can be installed using:
    $ git clone https://github.com/PX4/px4_ros_com.git ~/px4_ros_com_ros2/src/px4_ros_com
 $ git clone https://github.com/PX4/px4_msgs.git ~/px4_ros_com_ros2/src/px4_msgs
  • The Eigen3 library used by the transforms library should be in the both the desktop and base packages. It can be installed using:
    $ cd ~/px4_ros_com_ros2/src/px4_ros_com/scripts
 $ source build_ros2_workspace.bash

# 추가 정보

← ROS 2 Offboard Control Example →