Tools: add ROS 2 launch tests

[srmainwaring]

This PR adds two colcon packages that enable colcon to build and test the AP_DDS library in SITL.

There is a brief README in ./Tools/ros2 which includes instructions for running the examples in the Dockerfile_dev-ros Docker image.

Related issues

• AP_DDS: Run DDS smoke test in CI #23281
• Set up basic infrastructure for running a CLI smoke test ardupilot_gz#1
• Support launching gazebo sim to visualize vehicle ardupilot_gz#2

Motivation

The objective is to be able to build and test ArduPilot / ROS 2 integration using colcon with commands such as:

# build
colcon build --packages-select ardupilot_dds_tests

# test
colcon test --packages-select ardupilot_dds_tests

# test results
colcon test-result --all --verbose

We'd eventually like to be able to launch a simulation example as

ros2 launch ardupilot_sitl_gz copter.launch.py

A key requirement is that it should be easy for users familiar with ROS to install and run.

Some non-functional requirements are that the code required to support this be modular and reusable. In particular we'd like to reuse the code for launching in the tests.

Tasks

• Ensure tests exit / fail / time out if dependent packages cannot be found.
• Update ros2.repo file to point to https://github.com/ArduPilot/ardupilot.git master.

Details

Two packages are added to ./Tools/ros2.

ardupilot_sitl

A cmake project with a colcon package XML that presents the ArduPilot waf build as a cmake project, installing targets into the usual workspace folders expected by a ROS 2 colcon build. There are a couple of example launch files that will form component parts of the larger test suite for AP_DDS. These allow SITL and a non-interactive mavproxy session to be run from the ROS 2 CLI. For example:

ros2 launch ardupilot_sitl sitl.launch.py

ros2 launch ardupilot_sitl mavproxy.launch.py

The launch files support substitution actions and have launch arguments exposed, so that:

ros2 launch ardupilot_sitl sitl.launch.py --show-args
Arguments (pass arguments as '<name>:=<value>'):

    'command':
        Run ArduPilot SITL.
        (default: 'arducopter')

    'model':
        Set simulation model.
        (default: 'quad')

    'slave':
        Set the number of JSON slaves.
        (default: '0')

    'sim_address':
        Set address string for simulator.
        (default: '127.0.0.1')

    'speedup':
        Set simulation speedup.
        (default: '1')

    'instance':
        Set instance of SITL (adds 10*instance to all port numbers).
        (default: '0')

    'defaults':
        Set path to defaults file.
        (default: '/Users/rhys/Code/ros2/xrce-dds/ardupilot_ros2_ws/install/ardupilot_sitl/share/ardupilot_sitl/config/default_params/copter.parm')

Executables and default parameters are resolved in the launch scripts using the usual ROS 2 package tools.

ardupilot_dds_tests

This package will contain the test suite for the AP_DDS library. At present it has a launch file for creating the virtual ports needed for testing SITL:

ros2 launch ardupilot_dds_tests virtual_ports.launch.py tty0:=./dev/tty0 tty1:=./dev/tty1
[INFO] [launch]: All log files can be found below /Users/rhys/.ros/log/2023-04-07-14-14-46-569511-MacPro2-2.local-9436
[INFO] [launch]: Default logging verbosity is set to INFO
command:      socat
tty0:         ./dev/tty0
tty1:         ./dev/tty1
[INFO] [tty1 -1]: process started with pid [9442]
[tty1 -1] 2023/04/07 14:14:46 socat[9442] N PTY is /dev/ttys024
[tty1 -1] 2023/04/07 14:14:46 socat[9442] N PTY is /dev/ttys025
[tty1 -1] 2023/04/07 14:14:46 socat[9442] N starting data transfer loop with FDs [5,5] and [7,7]

There is an example test checking the time message published to the topic /ROS2_Time is received.

colcon test --packages-select ardupilot_sitl  ardupilot_dds_tests
Starting >>> ardupilot_dds_tests
Starting >>> ardupilot_sitl
Finished <<< ardupilot_sitl [0.54s]                               
--- stderr: ardupilot_dds_tests                     

=============================== warnings summary ===============================
test/test_time_msg_received.py::test_time_msgs_received
test/test_virtual_ports.py::test_read_stdout
  Warning: There is no current event loop

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
---
Finished <<< ardupilot_dds_tests [13.1s]

Summary: 2 packages finished [15.5s]
  1 package had stderr output: ardupilot_dds_tests

[Ryanf55]

Great work so far. Going to go ahead and do some testing to validate. A few minor points here and there.

[srmainwaring]

Update

• Moved launch files in ardupilot_dds_tests to ardupilot_sitl. Launch files being used downstream should not be in a project named *_test.
• Renamed the launch file for sitl_dds.
• Update README and refactor tests to accommodate launch file changes.

[tridge]

@Ryanf55 are you ok to approve this?

[Ryanf55]

LGTM. Minor updates can be done after it bootstraps.

[davidbuzz]

it does seem a bit weird to me to use colcon to execute cmake to execute waf ... when all three of them are build tools with similar capabilities.

[Ryanf55]

it does seem a bit weird to me to use colcon to execute cmake to execute waf ... when all three of them are build tools with similar capabilities.

If ArduPilot supported CMake, then it would only be two, but we're just using what's available. It's a bit of an odd marriage, but that's the best idea we had for this initial version.

[srmainwaring]

@davidbuzz it seems a bit strange at first, but it's a mechanism to translate ArduPilot's core repo into the ROS world without making any intrusive changes.

Here's some of the reasoning behind it: colcon is more of a package management system / build workflow coordinator than a build system like Python setuptools or cmake. ROS 2 ament, which extends colcon, dictates the structure of ROS 2 packages so the tooling can locate and find libraries, binaries and other resources. In order for those to work we need to make ArduPilot look and feel like a set of ROS 2 packages and follow their rules. They have no rules for waf, so the package has to be either cmake or Python. The Python packages have a number of limitations - very stringent directory structure and no symlink installs - so cmake was the better option. We also want to make ArduPilot appear as a number of ROS packages - one for core library, one for tests, perhaps others to come. This precludes setting the package structure at the ArduPilot root (which is also more intrusive). Finally, if we want to eventually distribute built packages as .debs or the widows equivalents, so ROS users can download pre-built versions of ArduPilot for ROS (which would make setting up new users that already have a working ROS much easier) then I think we need to go all in with the ROS build / install process. The resulting installation from the colcon build is completely divorced from the ArduPilot source structure and will run independently of that. I don't believe that is true for things like sim_vehicle.py and autotools which rely on things being in certain places in the ArduPilot source tree.