diff --git a/doc/xml/images/ATaskContext.svg b/doc/xml/images/ATaskContext.svg index ee2352e29..9233b5f13 100644 --- a/doc/xml/images/ATaskContext.svg +++ b/doc/xml/images/ATaskContext.svg @@ -16,7 +16,7 @@ sodipodi:version="0.32" inkscape:version="0.47pre4 r22446" version="1.0" - sodipodi:docname="ComponentArch-4.svg" + sodipodi:docname="ATaskContext.svg" inkscape:export-filename="/media/disk/XUM/2009/ComponentArch-2-1.png" inkscape:export-xdpi="100" inkscape:export-ydpi="100" @@ -1421,14 +1421,14 @@ inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="0.75738243" - inkscape:cx="471.14776" + inkscape:cx="302.8048" inkscape:cy="384.10833" inkscape:document-units="px" - inkscape:current-layer="layer1" + inkscape:current-layer="layer2" inkscape:window-width="1680" - inkscape:window-height="1000" - inkscape:window-x="-4" - inkscape:window-y="-3" + inkscape:window-height="976" + inkscape:window-x="0" + inkscape:window-y="25" showgrid="false" showguides="true" inkscape:guide-bbox="true" @@ -1441,7 +1441,7 @@ image/svg+xml - + @@ -2423,13 +2423,13 @@ OperationCallers
- Components Run in Threads + Typical application example for distributed control @@ -199,14 +199,14 @@
- Schematic Overview of the Hello Component. + Dynamic vs static loading of components - + - + The 'helloworld' executable is a static deployment of one component in a process, which @@ -651,7 +651,7 @@ Printing Interface of 'the_input_port' : // we assume this is done in all the following code listings : using namespace RTT; - class MyTask : publicRTT::TaskContext + class MyTask : public RTT::TaskContext { public: ATask(const std::string& name) : public TaskContext(name) {} diff --git a/doc/xml/orocos-typekit-plugin.xml b/doc/xml/orocos-typekit-plugin.xml index 745cf2be3..778b07bca 100644 --- a/doc/xml/orocos-typekit-plugin.xml +++ b/doc/xml/orocos-typekit-plugin.xml @@ -28,6 +28,12 @@ + + 2.0.1 + 7 Sept 2010 + ps + Updated status of typegen + 2.0.0 21 Jun 2010 @@ -65,9 +71,9 @@ The Orocos Type System : Typekits Most applications define their own classes or structs to exchange - data between components. It is possible to tell the RTT about these + data between components. It is easy to tell the RTT about these user defined types such that they can be displayed, stored to XML, - used in the scripting engine or even transfered over a network + used in the scripting engine and transfered between processes or over a network connection. @@ -96,8 +102,8 @@ Generating Typekits There are two tools available to generate Typekits for users. - The first one is orogen, which generates typekits from existing C++ - structs. The second is based on ROS, and generates typekits + The primary one is typegen, which generates typekits from existing C++ + structs defined in headers. The second is based on ROS, and generates typekits for ROS Messages (which are used in ros topics). @@ -115,22 +121,24 @@ - orogen + typegen Works with existing C++ classes Stable and tested Usable with the CORBA transport + Usable with the mqueue transport + Usable for scripting, XML. - Can not be used with classes with virtual functions. - Requires manual ruby setup + Requires to be built with 'autoproj' + Does not provide scripting constructors or operators - Being ported to RTT 2.x, Available for RTT 1.x + Available for RTT 2.x, Available for RTT 1.x @@ -146,7 +154,8 @@ Can not be used with existing C++ data types Experimental. Depends on ROS - Not compatible with the CORBA transport + Not compatible with the CORBA or mqueue transport + Does not provide scripting constructors or operators @@ -157,17 +166,55 @@ - + - These tools are under development and will mature during the - 2.x release cycles. In the meantime, users can fall back on - writing typekits manually as described below. + These tools are mature for most applications and users + should only write typekits by hand if they want to extend + beyond what typegen/rosgen offer. In practice, this means + adding specialized constructors or operators for scripting + for certain data types. - - + +
+ Using <command>typegen</command> + + Typegen requires that you have built the Orocos Toolchain with autoproj + and that you have 'sourced' the env.sh file in your shell. You + can use typegen as such: + cd myproject/src + typegen MyData.hpp -o typekit + + Which will create a directory 'typekit' which contains all necessary files to + build the typekit for all classes and structs defined in MyData.hpp. + To test your typekit, you can do afterwards: + cd myproject/src/typekit + CMAKE_INSTALL_PREFIX=/opt/orocos CMAKE_PREFIX_PATH=/opt/orocos cmake . + make install + + These variables tell cmake where to find Orocos and where to install the typekit: + + CMAKE_INSTALL_PREFIX : where to install to (a single directory) + CMAKE_PREFIX_PATH : where to look for the installed Orocos Toolchain (a list of directories, similar to the PATH variable) + + + + After make install finishes, you will see that your data types show up in the + deployer and taskbrowser applications, provided that the RTT_COMPONENT_PATH + variable contains the '/opt/orocos/lib/orocos' directory (= CMAKE_PREFIX_PATH + lib/orocos ). + +
+
+ Using <command>rosgen</command> + Under development. Consult the mailinglist or the wiki pages for this tool. +
Creating a Typekit in C++ + + + Only continue here if you are sure you can not use typegen/rosgen ! + + In case you don't use any of the typekit generators, you need to write a typekit yourself. This has been simplified in RTT