This PR adds a step to compile the ign-msgs protobufs for Python.

The CMake rule for generating the Python bindings is adapted from https://github.com/ignitionrobotics/ign-msgs/blob/main/src/CMakeLists.txt. An option is added to call protoc --python_out and custom targets are introduced to ensure the custom command is called.

The Python bindings are output to the build directory ${PROJECT_BINARY_DIR}/python/ignition/msgs/<type>_pb2.py

To use them include ${PROJECT_BINARY_DIR}/python in the PYTHONPATH

export PYTHONPATH=$PYTHONPATH:${PROJECT_BINARY_DIR}/python

The bindings may then be imported in Python as:

from ignition/msgs/<type>_pb2 import <Type>

This PR adds support for more than one version of Ignition

Use the approach taken in ign-rviz which introduces the environment variable IGNITION_VERSION to set the Ignition release and determine which versions of ignition libraries to use.

There is also an update to the pybind11_protobuf submodule that support builds on Linux/Ubuntu.

This PR adds bindings for some of the ignition-transport service functions

• List services
• Provide service info
• Call a service with a blocking request

There are also some other maintenance changes

• Rename the cmake project to python-ignition so it appears correctly in colcon graph
• Update dependency on math to ignition-math7 (garden)
• Update README with examples
• Add docstrings to the bound functions and classes
• Add bindings for dependencies (AdvertiseOptions and ServicePublisher etc.)

This PR restructures the pybind11 extension modules to better align with the conventions used in ign-gazebo

Interface changes

These changes alter the Python interface at the top level of import.

The import for ign-transport was

from ignition_transport import Node

and is now

from ignition.transport import Node

The example module for messages was

from ignition_msgs import make_time

and is now

from ignition.msgs.extras import make_time

The protobuf bindings are unchanged.

Bazel build changes

The Bazel build has been overhauled so that the extension modules are organised into the correct hierarchy. The Python examples will now run without any need to set the PYTHONPATH or modify the import prefix.

This PR updates the documentation and examples to focus on the CMake build

• Update the README to prioritise the building and using the examples with a CMake build
• Remove protobuf from submodules
• Remove unused comments and dependencies from CMakeLists.txt
• Minor updates to some examples

The Python bindings for ign-msgs are generated in the Bazel build via the build file ign-msgs9.BUILD. There is currently no equivalent for the CMake build.

The bindings are required for any of the Python examples that import an ignition messages using statements like:

from ignition.msgs.pose_pb2 import Pose

This PR provides an initial CMake build for macOS

Upstream dependencies

• There is an upstream dependency on CMake support for pybind11_protobuf. The submodule references a fork https://github.com/srmainwaring/pybind11_protobuf/tree/feature/cmake that has a CMake build.

Details

• CMakeLists.txt is updated to include the same targets as the Bazel build.
• The Python shebangs are corrected and files are made executable

This PR changes the import statement for the module ign_transport in the Python examples

For CMake builds the module is not prefixed by the project name, and the requirement to include the python_ignition prefix is an artefact of the Bazel build.

The README contains instructions for setting the PYTHONPATH to allow the use of either build method.

This PR enables the project to be built using Bazel.

Bindings for ign-msgs and ign-transport can be built using Bazel and the rules for Ignition contained in the ign-bazel project.

The Python module exposes the publish and subscribe interfaces of ignition::transport::Node and interfaces for supporting classes such as SubscribeOptions.

The CMake build for the bindings has been temporarily disabled as the CMakeList.txt for dependencies is not complete now that the mock-up has been replaced with ign-transport.

Python and C++ examples are provided that demonstrate how to use the bindings.

Add simple protobuf example and generate bindings

• Generate bindings for Python and C++
• For C++ compile the bindings into a library
• Provide example programs for C++ and Python

Add example using pybind11_protobuf

• Add external dependency on pybind11_protobuf
• Add simple C++ example with functions accepting protobuf messages
• Add pybind11 bindings
• Update python test example

Update pybind11_protobuf example

• Move functions using the time.proto to separate library
• Add example to main.cc
• Update the pybind11_protobuf submodule version

Disable the ignition_msgs test

• This test broken as ignition_msgs is missing a dependency from pybind11_protobuf

Rename the extension module to py_time_utils

Add test example from pybind11_protobuf

Update submodule for pybind11_protobuf

Remove unused protos

Add Bazel build files

• Add support for building with Bazel
• Update the python examples
• Add external protobuf patch required in pybind11_protobuf

Refactor time.proto -> time2.proto

• Rename example time.proto in preparation for building ignition_msgs
• Add dependency to ignition repos in workspace

Build protobuf bindings for a sample of ignition.msgs

• Add external build file for ignition-msgs
• Add python example binary to verify python protobuf bindings

Add ignition.msgs.pose

Add license

Add further ignition-msgs types

• Add cmd_vel2d, double, double_vm float, float_v
• Fix deps for pose_proto

Add message types

• Add message types for pid, twist, wrench, publish, publisher, subscribe. topic_info
• Add basic checks in python module

Add test module for ignition messages

Update README and add further module examples

• Add pybind11 examples for wrench and topic_info

Clean up project

• Leave only the ignition-msgs bindings and examples

Add .gitignore

Partial fix to cmake build

Clean up

• Remove unused header file
• Add license to cpp files
• Correct workspace name

Add placeholder for ignition-transport bindings

Add mock-up for ignition-transport Node

Refactor - rename msg module to align with transport

• Rename example module for ignition messages
• Rename python example scripts

Add mock-up for advertising topics

Initial draft of subscribe mock-up (callbacks)

Further additions to the subscribe mock-up

Rename ignition-msgs9 -> ign-msgs9

Enable use_fast_cpp_proto for Python bindings

• Add flag to .bazelrc (set to false though as there is still an unresolved issue with isinstance for the C++ implementation)
• Update C++ targets to use includes instead of copts
• Update ign-msgs9.BUILD to use Python protobuf rules from https://rules-proto-grpc.com
• Update version of pybind11_protobuf
• Update ign_msgs_example to highlight issue

Update README and examples

• Update README with install instructions and more detail about the examples
• Disable the failing case in ign_msgs_example.py
• Output the msg debug string to std::cout

Signed-off-by: Rhys Mainwaring [email protected]

The build instructions currently only work on macOS Big Sur 11.6.1 for a source install of Ignition Garden

The following changes are required to support Ubuntu 20.04 with Ignition Fortress

1. pybind11_protobuf depends on a later version of protobuf than available on Ubuntu 20.04 (3.6)

To upgrade the version of protoc:

git clone https://github.com/google/protobuf.git
cd protobuf/
git submodule update --init --recursive
./autogen.sh 
./configure 
make -j4
make check
sudo make install 
sudo ldconfig

$ protoc --version
libprotoc 3.19.1

2. CMake changes

• The top level CMakeLists.txt needs to set set(CMAKE_CXX_FLAGS "-fPIC") to fix a link error in the abseil-cpp library.
• For Ignition Fortress we need ign-msgs8 and ign-transport11
• There is a link issue when building a shared library for pybind11_native_proto_caster. Converting this to a static library resolves the issue, but there should be a better solution.

3. The ignition libraries will need to be built (clean) from source to ensure that consistent versions of protobuf are used throughout.

Some message types are not discovered when published using the Bazel build. This is not particular to Python, but also occurs for the C++ examples (so it does not appear to be a binding issue).

How to replicate

From terminal 1 run the C++ rover_publisher:

$ ./bazel-bin/python_ignition/rover_publisher
Publishing pose on topic [/pose], twist on topic [/twist]
Publishing pose on topic [/pose], twist on topic [/twist]
...

From terminal 2 run the C++ ign_topic_echo subscribing to /pose:

$ /bazel-bin/python_ignition/ign_topic_echo -t /pose 
header {
  stamp {
    sec: 4
    nsec: 513947250
  }
}
name: "base_link"
id: 9
position {
  x: 4.6053049700144255
  y: 1.9470917115432527
}
orientation {
  z: 0.19866933079506122
  w: 0.98006657784124163
}
...

From terminal 2 run the C++ ign_topic_echo subscribing to /twist:

$ /bazel-bin/python_ignition/ign_topic_echo -t /twist

In the second case no messages are displayed for the type ignition.msgs.Twist

Using the Python tools we can verify that both messages are published:

$ ./bazel-bin/python_ignition/python/ign_topic_list  
/pose
/twist

$ ./bazel-bin/python_ignition/python/ign_topic_info -t /pose
Publishers [Address, Message Type]:
  tcp://192.168.1.31:62260, ignition.msgs.Pose

$ ./bazel-bin/python_ignition/python/ign_topic_info -t /twist
Publishers [Address, Message Type]:
  tcp://192.168.1.31:62260, ignition.msgs.Twist

The issue is apparent with other messages types as can be seen by using the multi-message publisher:

From terminal 1:

$ ./bazel-bin/python_ignition/python/pub_all_msg_types

From terminal 2:

$ ./bazel-bin/python_ignition/python/ign_topic_list
/cmd_vel
/double
/double_v
/float
/float_v
/header
/pid
/pose
/publish
/quat
/subscribe
/time
/topic_info
/twist
/vector3d
/wrench

and then checking each topic in turn:

# working
$ ./bazel-bin/python_ignition/ign_topic_echo -t /double
header {
  stamp {
    sec: 15
    nsec: 21
  }
}
data: 10
...

# not working
$ ./bazel-bin/python_ignition/ign_topic_echo -t /double_v

The issue does not occur when running the examples built using the CMake build.