I believe the ROS 2 design article Interface Definition and Language Mapping should be formalized as a REP.

The REP should cover:

• Supported subset of IDL
• Mappings between IDL, ROSIDL, C, C++, Python for all data types available

The ROS 2 documentation has some outdated (incorrect) information (ros2/ros2_documentation#2884), and while I was updating this I figured that the details should be a REP rather than be in the docs.

This is my first time contributing a REP, so just wanted to make sure this is something we'd want before I start working on a PR. Also, how should I number the rep?

From @tfoote in #160 (comment):

I'd like to revisit the discussion for OpenCV. In particular we updated targets for everything to be 3.4 in #139 In particular comments at #139 (review) #139 (review)

We only pushed ahead to 3.3 based on this request: https://discourse.ros.org/t/opencv-3-3/2674 and that upgrade caused significant issues and debugging time. And we've had several request to fall back to 3.2 during the process. We thought that the new release would be fully backwards compatible but it was not and with the knowledge that I have now, I would have not chosen to make the upgrade if I could choose again.

With 3.2 available for our LTS platform (bionic) and 3.1 on the soon to be EOL'd platform (artful) the only major outlier is that stretch is older and only has 2.4.9.

I'd like to suggest that we fall back to using the system dependencies again instead of packaging OpenCV within ROS packages. On most of our platforms we're within a minor release.

To make things close to compatible I would propose that we backport buster's 3.2 to stretch, and then by July we'll only need to support 3.2 or higher. Which I believe is already available in Fedora and other platforms. And if there's something major blocking on Artful's 3.1 we could backport bionic's 3.2 or blacklist opencv3 on artful as it's very close to EOL.

There are significant advantages to using the upstream packages. In particular we are compatible with other system dependencies that rely on the system opencv installation. There are also standard replacement packages that enable hardware acceleration for systems with CUDA, Neon, etc maintained by the greater community. This would allow ROS users to leverage those builds.

We will also avoid significant build time on the ROS buildfarm, as well as maintaining a parallel custom package which has cost us a lot of time in this last cycle. In the past there's been issues with contrib not being available and the opencv version upstream being very out of date. Also as there's now the same major version of opencv on most platforms we need to be much more careful about declaring conflicts and making sure that our installation and the system one do not collide.

If people really do need to have the latest and greatest version of opencv, replacing the system version is relatively straight forward, it will just require that that any package depending on the custom version of opencv be compile from source. This is standard development processes, and with recent containerization technologies can even be relatively easily shared and reproduced.

I know that there are people that are strongly pushing for the bleeding edge latest things, but a large part of being in a distro is to be stable and solid for those not pushing the envelope. The new features will become available, but to provide the stability of a distro I think that we should not try to significantly push ahead of the upstream packaging.

@mikaelarguedas @vrabaud @clalancette

Follow-up from @clalancette:

I'm totally fine with this, as I agree the benefits of sticking to the system packages outweigh the benefits of having a newer package available. I'd even go further and suggest that we make sure to stick with whatever version we choose for the lifetime of the distribution, to make sure we don't have a repeat of what happened with OpenCV 3.3.

That all being said, I'm not one of the bleeding edge users that really want newer OpenCV features, so I'd like to hear from @vrabaud before we change this.

The draft for REP 149 contains multiple different parts. In order to not mix the discussion on those topics in a single ticket this issue is meant to focus on discussing the introduced conditional dependencies represented by the condition attribute.

In the "Suffix Frames Section":

For outdoor systems where it is desireable to work under the
north east down_ (NED) convention, define an appropriately transformed
secondary frame with the "_ned" suffix:

"desireable" should be spelled "desirable"

I encountered an issue in ROS in trying to install Jade on Ubuntu 14.04 running successfully without errors on my PowerPC G4 tower. I posted the error I get trying to install ROS :

http://answers.ros.org/question/218605/ros-jade-on-ubuntu-1404-e-unable-to-locate-package-ros-jade-desktop-full/

But my real question is... according to documentation there is no "REAL" architecture for ROS so why won't it work in "Ubuntu 14.04".. or is there an underlying issue I am unaware of.

Can it be done?.. can it run under PPC with 14.04.. or is there a modification that I should look for?

Let me know if this is a small or large job to do.. can I use the SOURCEs and reconstruct it to run under that environment?.. I figured that as a robot OS, it should be flexible with ANY device or hardware interface.

Hi,
I have question, on odom and base_footprint, especially when the robot is falling down or 4-legged walking.
I assume that humanoid robot did not know about the current waist position, but can estimate orientation from IMU sensors.

1. does odom correspond to the sensor based orientation and world reference based position of the waist?
2. does base_footprint respect the sensor based orientation and model based calculation of the height of the waist?
   if it is ok, the question is
3. how do you estimate the position of the odom, from the walking controllers? does that include any sensor data?
4. does base_footprint does not reflect any sensor data? what's happens if the robot falling down or 4-legged walking mode?

• update REP #79
• review/update catkin docs
  • added link to REP: http://wiki.ros.org/action/diff/catkin/migrating_from_rosbuild?action=diff&rev1=100&rev2=101
  • added link to REP and result space term: http://wiki.ros.org/action/diff/catkin/workspaces?action=diff&rev1=6&rev2=7
  • .rst based documentation @jack-oquin
• review/update catkin_tools docs and CLI help @wjwwood
• review/update wstool docs and CLI help @wjwwood
• review/update vcstools docs and CLI help @wjwwood

The following items seem to not require any documentation changes:

• catkin_make / catkin_make_isolated CLI help

The current way to specify a dependency needed for multiple build stages is with the separate tags <build_depend>, <exec_depend>, etc.

It seems more natural to have a way of way of specifying a package for multiple purposes in one declaration. Currently <depend> does this but only for a special case (<depend> is equivalent to <build_depend>, <build_export>, <exec> all at once).

I propose a for attribute on the depends tag which is a whitespace-separated list of one or more functional purposes, chosen from “build”, “build_export”, “buildtool”, “buildtool_export”, “exec”, “doc”, “test” (and possibly arbitrarily).

The default value of this attribute would be “build build_export exec” to preserve the semantics of existing depend tags. Thus the existing <build_depend> would become a synonym of <depend for=‘build’>.

This could be used with tools like rosdep as a natural way of filtering dependencies (e.g. rosdep install --from_path src --for build test doc).

REP 8 needs update on how-to-use Python with regards to catkin, replace section for Python version compatibility with link to web

See:

• http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

There is an error Malformed table shown here https://www.ros.org/reps/rep-2000.html
I use Chrome Version 107.0.5304.107 (Official Build) (64-bit)

Since we decided meta-packages must not be used for certain purposes, the REP should declare that a package.xml with a meta-package tag shall not use the respective tags. This means at least build_depend, buildtool_depend, test_depend. Not sure what else. Also we could state that non-metapackages may not depend on metapackages (unless already specified).

Hello,

I had a package failing that I wanted to just ignore for the time being and looked around for how to do it. The top hit I got was this ROS Answers post which points to REP-128. The top of that is as follows:

workspace_folder/         -- WORKSPACE
  src/                    -- SOURCE SPACE
    CMakeLists.txt        -- The 'toplevel' CMake file
    package_1/
      CMakeLists.txt
      package.xml
      ...
    package_n/
      CMakeLists.txt
      package.xml
      ...
  build/                  -- BUILD SPACE
    CATKIN_IGNORE         -- Keeps catkin from walking this directory

Based on that, I tried various ways to put a build/CATKIN_IGNORE folder somewhere with no success. After some frustration, I found this other post which showed just putting it in the top level of ./package_n (to use your terminology above). That worked for me.

The package that's failing happens to be part of a meta-package and neither of these worked:

~/catkin_ws/src/meta_pkg/build/CATKIN_IGNORE
~/catkin_ws/src/meta_pkg/failing_pkg/build/CATKIN_IGNORE

These worked:

~/catkin_ws/src/meta_pkg/CATKIN_IGNORE
~/catkin_ws/src/meta_pkg/failing_pkg/CATKIN_IGNORE

Perhaps REP-0128 is superseded, but I only found the same mention of build/CATKIN_IGNORE in REP-0133 when searching this repo.

Should this structure/suggestion be updated or clarified, or am I not understanding something correctly?

Hi,
I would like to propose adding an optional file attribution to the license tag in REP 149.
As I pointed out in ros-infrastructure/bloom#456, some OSS licenses require provision of license and copyright text when a user redistribute the software in a source or binary form. I think the file attribution will help a user or a tool to find right license or copyright text easily.

Thanks in advance.

This script is failing: https://github.com/ros-infrastructure/rep/blob/master/genrepindex.py

Called from the Makefile

http://build.ros.org/job/doc_independent-packages/287/console

22:46:54 # BEGIN SUBSECTION: rep: make html
22:46:54 + make html
22:46:54 mkdir -p _build/html
22:46:54 cd .. && make all
22:46:54 make[1]: Entering directory '/tmp/repositories/rep'
22:46:54 python genrepindex.py .
22:46:55 /usr/local/lib/python2.7/dist-packages/pkg_resources/py2_warn.py:22: UserWarning: Setuptools will stop working on Python 2
22:46:55 ************************************************************
22:46:55 You are running Setuptools on Python 2, which is no longer
22:46:55 supported and
22:46:55 >>> SETUPTOOLS WILL STOP WORKING <<<
22:46:55 in a subsequent release (no sooner than 2020-04-20).
22:46:55 Please ensure you are installing
22:46:55 Setuptools using pip 9.x or later or pin to `setuptools<45`
22:46:55 in your environment.
22:46:55 If you have done those things and are still encountering
22:46:55 this message, please comment in
22:46:55 https://github.com/pypa/setuptools/issues/1458
22:46:55 about the steps that led to this unsupported combination.
22:46:55 ************************************************************
22:46:55   sys.version_info < (3,) and warnings.warn(pre + "*" * 60 + msg + "*" * 60)
22:46:55 Traceback (most recent call last):
22:46:55   File "rep2html.py", line 87, in <module>
22:46:55     import docutils_readers_rep
22:46:55   File "/tmp/repositories/rep/docutils_readers_rep.py", line 13, in <module>
22:46:55     from docutils.parsers import rst
22:46:55   File "/usr/local/lib/python2.7/dist-packages/docutils/parsers/rst/__init__.py", line 75, in <module>
22:46:55     from docutils.parsers.rst import roles, states
22:46:55   File "/usr/local/lib/python2.7/dist-packages/docutils/parsers/rst/roles.py", line 78, in <module>
22:46:55     from docutils.utils.code_analyzer import Lexer, LexerError
22:46:55   File "/usr/local/lib/python2.7/dist-packages/docutils/utils/code_analyzer.py", line 19, in <module>
22:46:55     from pygments.formatters.html import _get_ttype_class
22:46:55   File "/usr/local/lib/python2.7/dist-packages/pygments/formatters/html.py", line 554
22:46:55     file=sys.stderr)
22:46:55         ^
22:46:55 SyntaxError: invalid syntax
22:46:55 Makefile:10: recipe for target 'rep-0010.html' failed
22:46:55 make[1]: *** [rep-0010.html] Error 1
22:46:55 make[1]: Leaving directory '/tmp/repositories/rep'
22:46:55 Makefile:6: recipe for target 'html' failed
22:46:55 make: *** [html] Error 2
22:46:55 Build step 'Execute shell' marked build as failure
22:46:55 $ ssh-agent -k
22:46:55 unset SSH_AUTH_SOCK;
22:46:55 unset SSH_AGENT_PID;
22:46:55 echo Agent pid 27593 killed;
22:46:55 [ssh-agent] Stopped.
22:46:55 Sending e-mails to: [email protected] [email protected]
22:46:55 Finished: FAILURE

We discussed different levels of stability here:

http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

 * Packages declare stability independently.  Racheting scale something like FeatureFrozen, APIFrozen, ABIFrozen etc. Need new REP for this to go into package.xml, in the export section. @tfoote replaces REP 9

The term "ROS Package" is used numerous times in REP 149 but not defined in that document. It should probably be defined in a REP or in some sort of authoritative glossary relevant to ROS2.

There is a definition in http://wiki.ros.org/Packages is clearly tailored to ROS1 as it is in terms of ROS_PACKAGE_PATH.

This term is needed to disambiguate from other types of packages (CMake project, Python project, etc.). It's unclear if "ROS Package" is more narrow, less narrow, or equivalent to "Packages recognized by colcon".

Originally raised in #265

System Integrity Protection was released with macOS 10.11 and is enabled by default. ROS 2 might require it to be disabled in order to function properly:
ros2/ros2#409
ros2/ros2#457

Since this is a significant constraint to the host system, it should probably be conspicuously documented in REP-2000 whether or not ROS supports macOS with SIP still enabled.

https://github.com/ros-infrastructure/rep/blob/6d7ef4a13764e88a2fc5da631956a9b398c24793/rep-0107.rst#protocol

Right now the REP states "The default publication rate is 1Hz."

This comment predates ROS2. With ROS2 it would seem more appropriate to use QoS instead of a fixed rate. I suggest the REP be updated to take advantage of ROS2 QoS.

Hi there,

We tried to use != in the condition of <build_depend> in the package.xml, but an error was thrown while building the package.

# package.xml
...
<test_depend condition="$QNX_BUILD != TRUE">tf2</test_depend>
...
[4.736s] 7: File 'package.xml' is invalid:
[4.737s] 7: /xxx/xxx/xxx/xxx/package.xml:24: element test_depend: Schemas validity error : Element 'test_depend', attribute 'condition': [facet 'pattern'] The value '$QNX_BUILD != TRUE' is not accepted by the pattern '[$A-Za-z0-9_\s<>=]*'.
[4.737s] 7: /xxx/xxx/xxx/xxx/package.xml:24: element test_depend: Schemas validity error : Element 'test_depend', attribute 'condition': '$QNX_BUILD != TRUE' is not a valid value of the local atomic type.

It looks like the xsd file from the download site
http://download.ros.org/schema/package_format3.xsd doesn't contain this PR and therefore ! isn't considered a valid character.

Is there a way to update the package_format3.xsd in the download site?

Thanks

They use python 2isms such as commas after except.

To test uncomment the python 3.3 line in the .travis.yaml added here: #73

We don't have good documentation and this should be more visible.

I cannot access to the contents.

$ curl -v http://www.ros.org/reps/rep-0000.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2605:bc80:3010:104::8cd3:962:80...
* Connected to www.ros.org (2605:bc80:3010:104::8cd3:962) port 80 (#0)
> GET /reps/rep-0000.html HTTP/1.1
> Host: www.ros.org
> User-Agent: curl/7.69.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Date: Tue, 21 Apr 2020 04:00:55 GMT
< Server: Apache
< Content-Length: 281
< Content-Type: text/html; charset=iso-8859-1
<
{ [281 bytes data]
100   281  100   281    0     0   1072      0 --:--:-- --:--:-- --:--:--  1072<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /reps/rep-0000.html
on this server.</p>
<hr>
<address>Apache Server at www.ros.org Port 80</address>
</body></html>

* Connection #0 to host www.ros.org left intact

$ curl -kv https://www.ros.org/reps/rep-0000.html
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2605:bc80:3010:104::8cd3:962:443...
* Connected to www.ros.org (2605:bc80:3010:104::8cd3:962) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
  CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2558 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=www.ros.org
*  start date: Mar 24 05:33:31 2020 GMT
*  expire date: Jun 22 05:33:31 2020 GMT
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
} [5 bytes data]
> GET /reps/rep-0000.html HTTP/1.1
> Host: www.ros.org
> User-Agent: curl/7.69.1
> Accept: */*
>
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Date: Tue, 21 Apr 2020 04:03:52 GMT
< Server: Apache
< Content-Length: 282
< Content-Type: text/html; charset=iso-8859-1
<
{ [5 bytes data]
100   282  100   282    0     0    414      0 --:--:-- --:--:-- --:--:--   414<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /reps/rep-0000.html
on this server.</p>
<hr>
<address>Apache Server at www.ros.org Port 443</address>
</body></html>

* Connection #0 to host www.ros.org left intact

REP 12 directs readers to the ros-users mailing list in several places:

• when mentioning Discussions-To (here):

  - If there is a mailing list for discussion of your new feature, add a
    Discussions-To header right after the Author header.  You should not
    add a Discussions-To header if the mailing list to be used is either
    years ago @tfoote Update discussion email to ros-users
    [email protected], or if discussions should be sent to you directly.
  

• as the final bullet under How to Use This Template (here):

  - Send your REP submission to the ROS developers at [email protected].
  

The mailing lists were migrated to @lists.ros.org, but mailman there now states:

This is the historical location of the ROS users mailing list. Please use http://discourse.ros.org/ to continue discussions.

Posts there will be archived here as well, but direct posting to this list has been turned off.

Should ROS Discourse now be listed as the place where REPs should be posted for initial review / discussion?

Or at least, I don't believe it was first posted on 30-Aug-2002 (here).

The package format 3 file is not present here : http://download.ros.org/schema/package_format3.xsd

The template function ros::param::param sets a variable either to the value of a parameter, or if not available, a predefined default value. In cases where the variable is passed straight to a constructor or function call and then disregarded, more streamlined code could be written if the result value could be retrieved as a function return value, rather than through an output variable.

For example, the code below:

std::string path;
std::string format;
double fps;

param("~path", path, "video.mpg");
param("~format", format, "MPEG");
param("~fps", fps, 30.0);

VideoRecorder recorder(path, format, fps);

Could be more succinctly written as:

VideoRecorder recorder(
    param<std::string>("~path", "video.mpg"),
    param<std::string>("~format", "MPEG"),
    param<double>("~fps", 30.0)
);

If an alternative definition of ros::param::param such as this was available:

template<typename T>
T param(const std::string& param_name, const T& default_val)
{
  T param_val;
  param(param_name, param_val, default_val);
  return value;
}

The REP 2 defines the scope of stacks (now packages) which should be covered by the REP process.

This list need to be reviewed and updated.

(for me at least) it takes up to 10 seconds to load the HTML versions of REPs served by www.ros.org/reps. Doesn't seem to matter which REP.

Looking at the Network tab of the Developer Tools in Firefox seems to indicate that images are slow to load but the main .html also contributes.

I've experienced this on multiple machines with multiple different internet connections, but it could still be "local" of course.

xref: ros-users thread http://ros-users.122217.n3.nabble.com/review-catkin-documentation-review-for-package-xml-format-2-td4021103.html

In Fuerte and Groovy the ros-base and ros-base-full variants don't exactly make sense because most of those packages are wet now.

REP-136 Releasing Third Party, Non catkin Packages instructions and examples should be updated for ROS2 (including replacing every catkin reference to ament). Is the recommendation to start a new reps for ROS2 or to update older ROS1 repos, in general?

In this case, updating REP136 would involve an update to the title of the rep, to Releasing Third Party, Non ament packages

We have run a scan on 3.3.1 source and found several vulnerabilities. OpenCV 3.4 source does not have these same vulnerabilities.

The ROS build server is currently creating a OpenCV 3.3.1 debian binary package. What's the plan for OpenCV 3.4 for ROS Kinetic? Will there be any debians for 3.4 in kinetic?

Just out of curiosity, i was wondering how it allocates the REP number.
As far as i see PRs, currently up to REP-2017 has been allocated already, so my expectation is next REP would be 2018? or is there any other official procedure to allocate the REP number instead?

The version paragraph of REP 127 is randomly centered and in a different font:

http://www.ros.org/reps/rep-0127.html#version

Given that there may be external links, I don't think the actual REP source should be changed, but this css contains the offending rule:

http://wiki.ros.org/moin_static197/rostheme/css/screen.css

I don't see where the rule is used on the actual ROS wiki, so it could either be dropped, or changed so that it's more specific, eg made #page #version rather than just #version.

The version attribute is defined as 3 period-separated components "MAJOR.MINOR.PATCH", which superficially looks like a Semantic Version.

It does not support full Semantic Versioning which admits prerelease versions and requires them to be respected for version precedence.

It also prevents SemVer build metadata, though this seems to be less useful since a single platform.xml generally applies to multiple build target platforms and because build metadata is ignored for precedence.

Mark 101, 108, 113 as replaced, due to out of date

See:

• http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

An agreed upon convention for how to layout a catkin package would enable to provide more automation in tools like catkin / catkin_simple.

I honestly do not understand the formula.

Here is what I propose. The next ROS will be released at the same time as the next Ubuntu, therefore it should support:

• the upcoming Ubuntu
• the latest released Ubuntu LTS (because PR2 are on those)
• the latest Ubuntu release (we cannot force developers to stick to an LTS but we can force them to only use the latest released Ubuntu)
• any Ubuntu version common to the previous two releases of ROS (so that developers can maintain those and develop the next version of ROS at the same time).

Sure those rules could be broken for any reason by the platform manager but those rules kindof match what we've done in the past:

Box Turtle (Feb 2010)
Ubuntu Hardy (rule 2)
Ubuntu Intrepid
Ubuntu Jaunty
Ubuntu Karmic (rule 3)

C Turtle (Aug 2010)
Ubuntu Jaunty (should not have been there according to those rules)
Ubuntu Karmic (rule 4)
Ubuntu Lucid (rule 2 and 3)
Ubuntu Maverick (rule 1)

Diamondback (Feb 2011)
rule 4 broken
Ubuntu Lucid (rule 2)
Ubuntu Maverick (rule 3)
Ubuntu Natty (rule 1)

Electric Emys (Aug 2011)
Ubuntu Lucid (rule 2 and 4)
Ubuntu Maverick (should not have been there according to those rules)
Ubuntu Natty (rule 3)
Ubuntu Oneiric (rule 1)

Fuerte Turtle (Mar 2012)
Ubuntu Lucid (rule 2 and 4)
Ubuntu Oneiric (rule 3)
Ubuntu Precise (rule 1)

Groovy Galapagos (Oct 2012)
Ubuntu Oneiric (rule 4)
Ubuntu Precise (rule 2 and 3)
Ubuntu Quantal (rule 1)

Hence for Hydro:

Hydro Medusa (Apr 2013)
Ubuntu Precise (rule 2 and 4)
Ubuntu Quantal (rule 3)
Ubuntu Raring (rule 1)

I (Oct 2013)
Ubuntu Precise (rule 2 and 4)
Ubuntu Raring (rule 3)
Ubuntu S (rule 1)

J (Apr 2014)
Ubuntu Precise (rule 2 and 4)
Ubuntu S (rule 3)
Ubuntu T LTS (rule 1)

K (Oct 2014)
Ubuntu S (rule 4)
Ubuntu T LTS (rule 2 and 3)
Ubuntu U (rule 1)

Problem

REP-147 recommends the use Odometry and Imu messages. These have covariance arrays. When using MicroXRCEDDS, this translates into 36 doubles of data, which is a ton of overhead for a tiny little STM32 running ArduPilot. Couple that with trying to push hundreds of messages a second, and we have a bit of a bandwidth problem, even when using ethernet.

I don't think the REP should be recommending using this messages with large covariances if they aren't used in embedded.

Use Case

ArduPilot supporting a REP-147 compliant MicroXRCEDDS interface.

References

px4_msgs only uses 9 elements for variances in Odometry. https://github.com/PX4/px4_msgs/blob/6c5a8e74eb2d173c0decb3feacd7e1932b64095b/msg/VehicleOdometry.msg#L23

px4_msgs doesn't even have covariances in the IMU message:
https://github.com/PX4/px4_msgs/blob/6c5a8e74eb2d173c0decb3feacd7e1932b64095b/msg/VehicleImu.msg#L9

This talk from the 2023 PX4 developer conference is great:
https://youtu.be/qly4tXj-aaA?si=umf_XRdErrm2Ll9f&t=1121

Thoughts from the ArduPilot dev team

Tridge, the lead dev of ArduPlane, says it's a "huge waste of bandwidth": ArduPilot/ardupilot#26187 (comment)

Alternatives

Modify the messages to allow leaving the covariances empty if they can't be populated. This won't be a good solution for humble which is what ~32% of people use according to the last ROS developer survey because it would break ABI.

REP 123 env var ROS_ETC_DIR needs conceptional change

See:

• http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

hello, please update this https://www.ros.org/reps/rep-2000.html to match this https://github.com/ros-infrastructure/rep/blob/master/rep-2000.rst
thank you!
@dirk-thomas @tfoote @mjcarroll

The draft for REP 149 contains multiple different parts. In order to not mix the discussion on those topics in a single ticket this issue is meant to focus on discussing the introduced compatibility version represented by the compatibility attribute.

The draft for REP 149 contains multiple different parts. In order to not mix the discussion on those topics in a single ticket this issue is meant to focus on discussing the introduced group dependencies represented by the group_depend and member_of_group tags.

Tonight the nightly build failed due to xsd validation failing. It doesn't look like a code change here but likely a library/dependency change, or a bug upstream that we need to pin until there's a fix.

https://build.ros.org/job/doc_independent-packages/630/console

02:10:46 rep-0124.rst (text/x-rst) -> rep-0124.html
02:10:47 rep-0119.rst (text/x-rst) -> rep-0119.html
02:10:47 rep-0000.rst (text/plain) -> rep-0000.html
02:10:47 python3 xsdValid.py
02:10:47 Traceback (most recent call last):
02:10:47   File "xsdValid.py", line 3, in <module>
02:10:47     import xmlschema
02:10:47   File "/usr/local/lib/python3.5/dist-packages/xmlschema/__init__.py", line 15, in <module>
02:10:47     from .resources import normalize_url, normalize_locations, fetch_resource, \
02:10:47   File "/usr/local/lib/python3.5/dist-packages/xmlschema/resources.py", line 13, in <module>
02:10:47     from elementpath import iter_select, Selector, XPath1Parser
02:10:47   File "/usr/local/lib/python3.5/dist-packages/elementpath/__init__.py", line 26, in <module>
02:10:47     from .xpath_token import XPathToken
02:10:47   File "/usr/local/lib/python3.5/dist-packages/elementpath/xpath_token.py", line 43, in <module>
02:10:47     from .tdop import Token, MultiLabel
02:10:47   File "/usr/local/lib/python3.5/dist-packages/elementpath/tdop.py", line 166
02:10:47     self._source: str = parser.source
02:10:47                 ^
02:10:47 SyntaxError: invalid syntax
02:10:47 Makefile:26: recipe for target 'xsdvalid' failed
02:10:47 make[1]: Leaving directory '/tmp/repositories/rep'

REP 3 needs update for new release cycle and Indigo

Reference:

• http://www.ros.org/wiki/Distributions/Timeline
• http://etherpad.ros.org/p/ROS_Platform_Group_2013-06-26

It would be nice to add some flexibility in dependencies. While package.xml is used for sequencing builds, it's currently unsuitable for generating a list of concrete package dependencies since some packages are optional.

@dirk-thomas

Please feel free to describe how colcon should determine that based on the available information from the package manifests.

...

Group dependencies are not necessarily optional. There are cases where you e.g. need at least one of package from the group in order to work properly. That semantic isn't encoded in the manifest because the community wasn't able to reach a consensus when this was proposed (I don't have a link to that discussion at hand).
Therefore I don't think an option to just ignore group dependencies is sufficient.

Originally posted by @dirk-thomas in ros2/rmw_dds_common#16 (comment)

What email address should be used for orphaned packages? REP 140 currently recommends [email protected] which seems to be outdated.