- 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 wiki
- RTT 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
- Using Eclipse and Orocos
- Using Git and Orocos
- Wiki for site admins
- iTaSC wiki
D. Fourth day
Stephen gives an overview of the current log4cpp + Orocos architecture and how he accomplished real-time logging. Log4cpp supports
- 1 category can have 0..* appenders
- 1 appender has 0..1 category (0 makes no sense though)
- A RTString type that uses tlsf, but still lives in OCL.
- A real-time logging category type. Any number of these can be created with their own 'org.orocos.rtt.xyz' scope.
- A file appender component type. Appending over the network (CORBA) is untested though
Decisions for v2.0
- Deprecate RTT::Logger in v2.0
- Move OCL::String into RTT
- Move log4cpp itself into RTT (or into orocos-log4cpp gitorious project)
v2.2 or later
- Move OCL::Logging into RTT and port to v2.x
- Make LoggingService support lookup of ports by category (called via operation to do so)
- Support multiple appenders per category
- Either logging messages go to stderr if appender not yet connected to category, or they continue to get discarded
- Deployer by default starts LoggingService and FileAppender (to orocos.log). User can turn this behaviour off with a command line parameter, allowing them to configure the logging system via a site deployment file.
- Add streaming capability : logger->debug << xyz;
- Replace RTT::Logger with calls to RTT::Logging framework
- Complete OCL::String plugin to support use within scripting
- Add LoggingPlugin
- support use from scripting to query, modify and use OCL::Category
- Add additional appenders (eg socket)
Services discussionPeter explains how services made their entry into the design and how they can be used.
- Services have to have different names from ports (v2)
- TaskContext has a default service (this->provides())
- TC is really a service container/executor.
- Properties and operations must be in a service
- Ports were _not_ in a service. This will be changed such that ports belong to a Service. A Provides Service can have both input and output ports. This is reasonable and meets real-world semantics, however, it does sound slightly contradictory. Must be well explained with examples.
- Talking of dropping the “Providers” in “ServiceProviders”, and just having “Services” and “ServiceRequestors”