[Documentation] [TitleIndex] [WordIndex

ROS 開発者ガイド

ROSは大きなシステムであり、多くの人が多くのコードを書いています。 これらのコードを効率的に管理できるようにするために、 我々は下記の開発ガイドラインを作成しました。 是非、あなたのROS用コードも 下記のガイドラインに従うようにしてください。

See also:

ソースコード管理

ROSはSubversion, Mercuria, Git, Bazaarなどの ソースコード管理システムに対応しています。

また、現在ROSのコミュニティ内でも行われているように、 あなたのコードをGitHubやBitbucket, Google Codeなどの ソース共有サイトで公開して共有することも大歓迎です。

ちなみにROSのメインコードはcode.ros.org, kforge.ros.orgで

公開されています。 The main ROS code base is hosted in several organization units on github.com. For the recommended repository usage please see RecommendedRepositoryUsage

Bug tracking

We use separate bug trackers for each package which include bug reports, enhancement requests, and task assignments. Usually you will find the link to the package-specific bug tracker on the Wiki page of the package.

For packages hosted on GitHub this is commonly the issue tracker of the repository.

The maintainer will assign a milestone to each reported issue. This should give the reporter a reasonable feedback when this issue will be addressed. These milestone are usually ROS releases (like Groovy or Hydro) or more fine grain milestones (like Hydro beta 1). Furthermore the milestone untargeted is used when a issue will likely not get fixed / implemented. That can be either due to lack of time of the developer or other viability considerations.

To give users some idea as to whether a fix has made it to the release repository, the maintainer should either mention the intended release version while closing the issue report, or setup milestones for every minor release and tag the issue report with the next milestone. This will make the issue self-contained in determining whether a fixed release is available to the user.

When you find a bug, open a ticket. When you want a feature, open a ticket. Emails or posting on answers.ros.org or the mailing list are more likely to get lost. It's far less likely to be forgotten if there's a ticket.

If you are unsure for which package the issue should be filled or if an issue you are facing is actually a bug please ask on answers.ros.org first.

Code layout

ROS code is organized into packages, and packages can be collected into a single repository. Packages are represent units of code that you build

Especially if using GitHub it is recommended to create a README.md at the root of your repository to explain to users what to find in the repository. It is recommended to link to the package documentation on the ROS wiki for the contained packages. See this article for formatting help.

Packaging

The ROS package and build system relies on manifest.xml files.

Here is a template you can fill in for roscpp nodes:

<package>
  <description brief="BRIEF DESCRIPTION">
     LONGER DESCRIPTION
  </description>
  <author>You/you@willowgarage.com</author>
  <license>BSD</license>
  <url>http://wiki/YOURPACKAGE</url>
  <depend package="roscpp"/>
</package>

And here is one for rospy nodes:

<package>
  <description brief="BRIEF DESCRIPTION">
     LONGER DESCRIPTION
  </description>
  <author>You/you@willowgarage.com</author>
  <license>BSD</license>
  <url>http://wiki/YOURPACKAGE</url>
  <depend package="rospy"/>
</package>

GUI toolkits

We have migrated all new GUI development to rqt, a Qt-based GUI framework for ROS. Much of the existing code that were built before fuerte used wxWidgets, which has not maintained good cross-platform compatibility. Please consider using rqt for any new GUI development. Development instruction (including license consideration when writing in python) is available there.

Building

The basic build tool is CMake (more).

Licensing

ROS is an Open Source project. We aim to support a wide variety of users and developers, from grad students to entrepreneurs.

Under the Berne Convention, the author of a work automatically holds copyright, with or without a formal statement to that effect. However, making copyright explicit is helpful in long-term project management.

Debugging

All standard debugging tools work within ROS, including but not limited to:

General advice:

Testing

We use two level of testing:

We have established best practices and policies for writing and running tests.

If you are developing in the ros, ros-pkg, or wg-ros-pkg repositories, a build farm is set up to regularly test the build and run automated tests on a variety of architectures. If the build or tests stop working after one of your commits, you will get an email informing you of the error and will be expected to fix it. See the AutomatedTesting guidelines for more details.

Documentation

Releasing

The standard process for releasing code to the ROS community is described on the release page.

Standardization

Deprecation

As soon as there are users of your code, you have a responsibility not to pull the rug out from under them with sudden breaking changes. Instead, use a process of deprecation, which means marking a feature or component as being no longer supported, with a schedule for its removal. Give users time to adapt, which is usually one release cycle, then do the removal.

Deprecation can happen at multiple levels, including:

Large data files, Large test files

Large files (anything over 1MB, really) often don't belong in the *-ros-pkg repositories, especially if they are just used for unit tests. These large files affect the time that it takes to checkout the repository, whether or not someone is building your package.

Large data files should be hosted in a public web hosting site. You can also just place the file you need on a web server. Hosting for some files can be provided at downloads.ros.org please contact ros-release@code.ros.org for more info.

To download this file for building, use the rosbuild_download_test_data(URL MD5SUM) macro. For example:

rosbuild_download_test_data(http://code.ros.org/svn/data/robot_pose_ekf/zero_covariance.bag test/zero_covariance.bag 0a51b4f5001f446e8466bf7cc946fb86)



2024-03-23 12:39