Rationale

You want to build debian packages once, so that you can install on multiple machines without building from source on each.

Assumptions

1. You are building for gnulinux only.
2. You have "svn-b", etc, alises setup (see "man svn-buildpackage").
3. You are using Synaptic as your package manager.
4. Example code is for Orocos v1.8, but also applies to later versions, including 2.x
5. BASE_DIR is whatever directory you want to put everything into. Click below to read the rest of this post.

Because of single thread serialization, something unexpected for the programmer happens.

1) You expect TaskA to be independent from TaskB, but it isn't. If you think it is a problem of resources of the computer, change the activity frequency of 1 of the two tasks.

Suggestion: A) let the programmer choose if single thread serialization is used or not. B) keep 1 thread for 1 activity policy for default. It will help less experienced user to avoid common errors. Click below to read the rest of this post.

INTRODUCTION

Please be concise and provide a short example and your motivation to include it in RTT. Ask first yourself:

• "Am I the only beneficiary of this new feature?"
• "Can this feature be obtained with a simple layer on the top of RTT ?"

If you answered "no" to both the questions and you have already debated the new future in the Developers forum, please post here your suggestion.

INTRODUCTION

You can edit this page to post your contribution to OrocosRTT 2.0. Please, keep your comment concise and clear: if you want to launch a long debate, you can still use the Developers Forum! Short examples can help other people understanding what you mean.

---

A) According to the section 4. of the Orocos Component Builder's Manual, the callback of a synchronous event is executed inside the thread of the event's emitter. Click below to read the rest of this post.

Branches versus Trunk

With the term trunk, we denote the main line (HEAD) of development of which new releases are spawned from time to time.

(Suggestions for changes to this plan are discussed on the Orocos-dev mailing list.)

Objectives

The objectives of this plan are to provide:

1. A clear roadmap for Orocos RTT
2. Higher-quality releases
3. Support for more platforms, being Operating Systems, hardware or robot architectures.
4. Continued encouragement of code improvements
5. More predictable release schedules
6. More frequent releases