- European Robotics Forum 2011 Workshop on the Orocos Toolchain
- European Robotics Forum 2012: workshops
- Geometric relations semantics
- KDL wiki
- Kuka LBR user group
- Links of Orocos components
- OCL v1.x wiki
- RTT v1.x wiki
- Documentation suggestions
- Examples and Tutorials
- Frequently asked questions (FAQ)
- RTT Dictionary
- RTT on MS Windows
- The 1st RTT Developers Workshop
- The Road to RTT 2.0
- Goals for RTT 2.0
- Contribute! Which weakness have you detected in RTT?
- Contribute! Suggest a new feature to be included in RTT 2.0.
- Create Reference Application Architectures
- Detailed Roadmap
- Full distribution support
- RTT 2.0.0-beta1
- RTT 2.0.0-beta2
- RTT and OCL Cleanup
- Real time logging
- Redesign of the data flow interface
- Simplified, more robust default activities
- Streamlined Execution Flow API
- Upgrading from RTT 1.x to 2.0
- Using Eclipse and Orocos
- Using Git and Orocos
- Toolchain v2.x
- Wiki for site admins
- iTaSC wiki
Provides vs Requires interfaces
Users can express the 'provides' interface of an Orocos Component. However, there is no easy way to express which other components a component requires. The notable exception is data flow ports, which have in-ports (requires) and out-ports (provides). It is however not possible to express this requires interface for the execution flow interface, thus for methods, commands/messages and events. This omission makes the component specification incomplete.
One of the first questions raised is if this must be expressed in C++ or during 'modelling'. That is, UML can express the requires dependency, so why should the C++ code also contain it in the form of code ? It should only contain it if you can't generate code from your UML model. Since this is not yet available for Orocos components, there is no other choice than expressing it in C++.
A requires interface specification should be optional and only be present for:
- completing the component specification, allowing better review and understanding
- automatically connecting component 'execution' interfaces, such that the manual lookup work which you need to write today can be omitted.
We apply this in code examples to various proposed primitives in the pages below.