• The directory /opt/www/bruyninckxh2/web/tmp/drutex-517f1d55d69da8cfcb7442bac085ea8d-1 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-517f1d55d69da8cfcb7442bac085ea8d-2 has been created.

Getting started

I am trying to get started using OROCOS.

I already found out that it is quite hard to find the right documentation
and the best way to get started just by reading the orocos webpages.

Would it make sense to document the problems I encounter, so that the
learning curve for new users could be made a little less steep? I mean, if
I spend the effort to document this, will anyone use this information to
actually improve the documentation and/or add information to the website?

Johan Cockx

where to find solutions installation related problems?

I am trying to install OROCOS for the first time.
I'm using the "Quick Installation Instructions for GNU/Linux", but I get a compile error at 68% when I type "make".
I haven't found a solution for my problem in the manual, the orocos website, forum, or other websites.

Supposing I'm not the only one with these kind of problems, where can I find solutions for installation related problems, or where am I supposed to ask for help for these kind of problems?

Thanks for any kind of help.

where to find solutions installation related problems?

b [dot] j [dot] burgers [..] ... wrote:
> I am trying to install OROCOS for the first time.
> I'm using the "Quick Installation Instructions for GNU/Linux", but I get a compile error at 68% when I type "make".

You should state the error you get. Merely saying, "..I get a compile
error at 68%.." isn't sufficient information to think of a solution.

While you are at it, you could tell us what Linux distribution you are
using, the orocos target you are compiling (gnulinux, lxrt.. ? ), the
compiler version and so on.

Regards,
Sagar

installation problem

Thanks for the quick response.
I thought this wasn't the approprate place for these kind of questions, so didn't give much info, but seems it is.

OS: 2.6.30-ARCH, arch linux (with KDEmod)
GCC: 4.4.0 20090630 (prerelease)
cmake version: 2.6-patch 4

from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4
From the output (at the bottum of the post) everything seems fine, except that the Xercers headers are not found.
When running "make" I get this output:
[ 68%] Building CXX object src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o
/home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In function 'std::string float_to_string(float)':
/home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:183: error: 'snprintf' was not declared in this scope
make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o] Error 1
make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
make: *** [all] Error 2
Now using "make install" gives the same errors.

In case it is important that the Xercers headers are found.
My .profile:
# .bash_profile
#needed for orocos:
export LD_LIBRARY_PATH=$ACE_ROOT/lib:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/lib:$LD_LIBRARY_PATH
ACE_ROOT=/home/bin/ACE_wrappers ; export ACE_ROOT
TOA_ROOT=$ACE_ROOT/TAO; export TOA_ROOT
JAVA_HOME=/opt/java/bin
PATH=$PATH:$JAVA_HOME:/home/bin:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/bin
export JAVA_HOME
export PATH

Output of ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4:
Orocos configure script. WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
Invoking: ' /usr/bin/cmake .. -DCMAKE_INSTALL_PREFIX=/home/bin/orocos/orocos-rtt-1.8.4'
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Orocos RTT version (1.8.4)
Setting build type to 'RTT'
-- Build type set to 'RTT' by user.
-- Looking for Boost/C++ headers --
-- Looking for Boost headers - found
-- Looking for Xerces - headers not found
CMAKE_VERSION: 2.6.4
-- Detected gcc4: 4.4.0

-- Found Doxygen: /usr/bin/doxygen
-- Found Doxygen -- API documentation can be built
Disabling packaging for version 2.6
-- Configuring done
-- Generating done
-- Build files have been written to: /home/Bas/Downloads/orocos-rtt-1.8.4/build

OK: configure done. Now issue 'make'.

Thanks for the help!!

Ruben Smits's picture

installation problem

On Mon, Aug 3, 2009 at 1:48 PM,
b [dot] j [dot] burgers [..] ...<b [dot] j [dot] burgers [..] ...> wrote:
> Thanks for the quick response.
> I thought this wasn't the approprate place for these kind of questions, so didn't give much info, but seems it is.
>
> OS: 2.6.30-ARCH, arch linux (with KDEmod)
> GCC: 4.4.0 20090630 (prerelease)
> cmake version: 2.6-patch 4
>
> from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
> ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4
> >From the output (at the bottum of the post) everything seems fine, except that the Xercers headers are not found.

The Xerces headers are not a problem. The are not really needed.

> When running "make" I get this output:
>    [ 68%] Building CXX object src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o
>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In function 'std::string float_to_string(float)':
>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:183: error: 'snprintf' was not declared in this scope
>    make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o] Error 1
>    make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
>    make: *** [all] Error 2

This is strange, normally snprintf is declared in cstdio, can you make
sure that it is? Maybe it is an gcc 4.4 compiler issue (i currently
use gcc 4.3 and do not have the problem you are having)

> Now using "make install" gives the same errors.

That normal, make install tries to do make again since make failed.

> In case it is important that the Xercers headers are found.
> My .profile:
>    # .bash_profile
>    #needed for orocos:
>    export LD_LIBRARY_PATH=$ACE_ROOT/lib:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/lib:$LD_LIBRARY_PATH
>    ACE_ROOT=/home/bin/ACE_wrappers ; export ACE_ROOT
>    TOA_ROOT=$ACE_ROOT/TAO; export TOA_ROOT
>    JAVA_HOME=/opt/java/bin
>    PATH=$PATH:$JAVA_HOME:/home/bin:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/bin
>    export JAVA_HOME
>    export PATH
>
> Output of ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4:
>    Orocos configure script.  WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
>    Invoking: '  /usr/bin/cmake ..  -DCMAKE_INSTALL_PREFIX=/home/bin/orocos/orocos-rtt-1.8.4'
>    -- The C compiler identification is GNU
>    -- The CXX compiler identification is GNU
>    -- Check for working C compiler: /usr/bin/gcc
>    -- Check for working C compiler: /usr/bin/gcc -- works
>    -- Detecting C compiler ABI info
>    -- Detecting C compiler ABI info - done
>    -- Check for working CXX compiler: /usr/bin/c++
>    -- Check for working CXX compiler: /usr/bin/c++ -- works
>    -- Detecting CXX compiler ABI info
>    -- Detecting CXX compiler ABI info - done
>    Orocos RTT version  (1.8.4)
>    Setting build type to 'RTT'
>    -- Build type set to 'RTT' by user.
>    -- Looking for Boost/C++ headers --
>    -- Looking for Boost headers - found
>    -- Looking for Xerces - headers not found
>    CMAKE_VERSION: 2.6.4
>    -- Detected gcc4: 4.4.0
>
>    -- Found Doxygen: /usr/bin/doxygen
>    -- Found Doxygen -- API documentation can be built
>    Disabling packaging for version 2.6
>    -- Configuring done
>    -- Generating done
>    -- Build files have been written to: /home/Bas/Downloads/orocos-rtt-1.8.4/build
>
>    OK: configure done. Now issue 'make'.
>
This looks ok.

Ruben

installation problem

Hi all, I got an issue during installation of orocos-rtt. The message
returned was:

*****************************************************************
Orocos configure script. WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
Invoking: ' CXX=/usr/bin/g++ /usr/bin/cmake ..
-DCMAKE_INSTALL_PREFIX=/usr/local/orocos-rtt-1.8.3/'
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
Orocos RTT version (1.8.3)
Setting build type to 'RTT'
-- Build type set to 'RTT' by user.
-- Looking for Boost/C++ headers --
-- Looking for Boost headers - found
-- Looking for Xerces - headers not found
CMAKE_VERSION: 2.4.7
-- Detected gcc4: 4.1.3

-- Looking for doxygen...
-- Looking for doxygen... - found /usr/bin/doxygen
-- Looking for dot tool...
-- Looking for dot tool... - found /usr/bin/dot
-- Found Doxygen -- API documentation can be built
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/orocos-rtt-1.8.3/build

OK: configure done. Now issue 'make'.
*************************************************************************
It was doing fine:

root@breno-HP:/usr/local/orocos-rtt-1.8.3/build# make
Scanning dependencies of target orocos-rtt-dynamic_gnulinux
[ 0%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ActionInterface.o
[ 0%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/FunctionGraph.o
[ 1%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/MarshallingAccess.o
[ 1%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConnectionC.o
[ 3%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ProgramInterface.o
[ 3%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/VectorComposition.o
[ 4%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/CommandC.o
[ 4%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/signal_base.o
[ 4%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ExecutionAccess.o
[ 6%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/FactoryExceptions.o
[ 6%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Property.o
[ 8%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionDuration.o
[ 8%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/PropertyBag.o
[ 9%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/EdgeCondition.o
[ 9%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionDSDuration.o
[ 9%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/TaskCore.o
[ 11%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/EventC.o
[ 11%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/CommandProcessor.o
[ 13%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/AttributeRepository.o
[ 13%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/MultiVector.o
[ 14%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataSource.o
[ 14%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/StateDescription.o
[ 14%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Types.o
[ 16%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Logger.o
[ 16%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionComposite.o
[ 18%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataSourceCondition.o
[ 18%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionBool.o
[ 19%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/NonPeriodicActivity.o
[ 19%] Building CXX object
src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataFlowInterface.o
/usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp: In member function
?RTT::OperationInterface* RTT::DataFlowInterface::createPortObject(const
std::string&)?:
***********************************************************************

Now the error after make command:

/usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:177: error: invalid
use of undefined type ?struct RTT::TaskObject?

/usr/local/orocos-rtt-1.8.3/src/PortInterface.hpp:49: error: forward
declaration of ?struct RTT::TaskObject?

/usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:179: error: invalid
use of undefined type ?struct RTT::TaskObject?

/usr/local/orocos-rtt-1.8.3/src/PortInterface.hpp:49: error: forward
declaration of ?struct RTT::TaskObject?

/usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:181: error: cannot
convert ?RTT::TaskObject*? to ?RTT::OperationInterface*? in return

make[2]: ***
[src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataFlowInterface.o] Error
1

make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
make: *** [all] Error 2
***********************************************************************

Thanks for any support!!!

Breno

Ruben Smits's picture

installation problem

You shouldn't use rtt 1.8.3, there was a compile error inside which
you hit. This was fixed in rtt 1.8.4.

Ruben

On Mon, Aug 3, 2009 at 6:18 PM, breno [..] ...<breno [..] ...> wrote:
> Hi all, I got an issue during installation of orocos-rtt. The message
> returned was:
>
> *****************************************************************
> Orocos configure script.  WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
> Invoking: ' CXX=/usr/bin/g++ /usr/bin/cmake ..
> -DCMAKE_INSTALL_PREFIX=/usr/local/orocos-rtt-1.8.3/'
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Check size of void*
> -- Check size of void* - done
> -- Check for working CXX compiler: /usr/bin/g++
> -- Check for working CXX compiler: /usr/bin/g++ -- works
> Orocos RTT version  (1.8.3)
> Setting build type to 'RTT'
> -- Build type set to 'RTT' by user.
> -- Looking for Boost/C++ headers --
> -- Looking for Boost headers - found
> -- Looking for Xerces - headers not found
> CMAKE_VERSION: 2.4.7
> -- Detected gcc4: 4.1.3
>
> -- Looking for doxygen...
> -- Looking for doxygen... - found /usr/bin/doxygen
> -- Looking for dot tool...
> -- Looking for dot tool... - found /usr/bin/dot
> -- Found Doxygen -- API documentation can be built
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /usr/local/orocos-rtt-1.8.3/build
>
> OK: configure done. Now issue 'make'.
> *************************************************************************
> It was doing fine:
>
> root@breno-HP:/usr/local/orocos-rtt-1.8.3/build# make
> Scanning dependencies of target orocos-rtt-dynamic_gnulinux
> [  0%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ActionInterface.o
> [  0%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/FunctionGraph.o
> [  1%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/MarshallingAccess.o
> [  1%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConnectionC.o
> [  3%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ProgramInterface.o
> [  3%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/VectorComposition.o
> [  4%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/CommandC.o
> [  4%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/signal_base.o
> [  4%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ExecutionAccess.o
> [  6%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/FactoryExceptions.o
> [  6%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Property.o
> [  8%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionDuration.o
> [  8%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/PropertyBag.o
> [  9%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/EdgeCondition.o
> [  9%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionDSDuration.o
> [  9%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/TaskCore.o
> [ 11%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/EventC.o
> [ 11%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/CommandProcessor.o
> [ 13%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/AttributeRepository.o
> [ 13%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/MultiVector.o
> [ 14%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataSource.o
> [ 14%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/StateDescription.o
> [ 14%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Types.o
> [ 16%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/Logger.o
> [ 16%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionComposite.o
> [ 18%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataSourceCondition.o
> [ 18%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/ConditionBool.o
> [ 19%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/NonPeriodicActivity.o
> [ 19%] Building CXX object
> src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataFlowInterface.o
> /usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp: In member function
> ‘RTT::OperationInterface* RTT::DataFlowInterface::createPortObject(const
> std::string&)’:
> ***********************************************************************
>
> Now the error after make command:
>
> /usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:177: error: invalid
> use of undefined type ‘struct RTT::TaskObject’
>
> /usr/local/orocos-rtt-1.8.3/src/PortInterface.hpp:49: error: forward
> declaration of ‘struct RTT::TaskObject’
>
> /usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:179: error: invalid
> use of undefined type ‘struct RTT::TaskObject’
>
> /usr/local/orocos-rtt-1.8.3/src/PortInterface.hpp:49: error: forward
> declaration of ‘struct RTT::TaskObject’
>
> /usr/local/orocos-rtt-1.8.3/src/DataFlowInterface.cpp:181: error: cannot
> convert ‘RTT::TaskObject*’ to ‘RTT::OperationInterface*’ in return
>
> make[2]: ***
> [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/DataFlowInterface.o] Error
> 1
>
> make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
> make: *** [all] Error 2
> ***********************************************************************
>
> Thanks for any support!!!
>
> Breno
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

installation problem

On Fri, Aug 7, 2009 at 09:40, Ruben Smits<ruben [dot] smits [..] ...> wrote:
> You shouldn't use rtt 1.8.3, there was a compile error inside which
> you hit. This was fixed in rtt 1.8.4.

Maybe I should rename the source tarball version from 1.8.3 to
1.8.3-do-not-use ?

Peter

installation problem

On Aug 10, 2009, at 09:18 , Peter Soetens wrote:

> On Fri, Aug 7, 2009 at 09:40, Ruben
> Smits<ruben [dot] smits [..] ...> wrote:
>> You shouldn't use rtt 1.8.3, there was a compile error inside which
>> you hit. This was fixed in rtt 1.8.4.
>
> Maybe I should rename the source tarball version from 1.8.3 to
> 1.8.3-do-not-use ?

Maybe, but also, the web page lists v1.8.4 as the latest. That should
be enough to make someone grab that ...?

Alternatively, just remove v1.8.3 tarball? It's no use after all ...
but then what should we do with OCL v1.8.1? Similar problem.
Stephen

Ruben Smits's picture

installation problem

Ok, i located the problem.

rtconversion.cpp misses the cstdio include. This is already fixed in
rtt-trunk but it is not merged into the 1.8 branch. You can try with
rtt-trunk (get it using git or svn) or you can wait until Peter
releases a new version of 1.8 which includes this fix.

Ruben

On Mon, Aug 3, 2009 at 3:53 PM, Ruben Smits<ruben [dot] smits [..] ...> wrote:
> On Mon, Aug 3, 2009 at 1:48 PM,
> b [dot] j [dot] burgers [..] ...<b [dot] j [dot] burgers [..] ...> wrote:
>> Thanks for the quick response.
>> I thought this wasn't the approprate place for these kind of questions, so didn't give much info, but seems it is.
>>
>> OS: 2.6.30-ARCH, arch linux (with KDEmod)
>> GCC: 4.4.0 20090630 (prerelease)
>> cmake version: 2.6-patch 4
>>
>> from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
>> ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4
>> >From the output (at the bottum of the post) everything seems fine, except that the Xercers headers are not found.
>
> The Xerces headers are not a problem. The are not really needed.
>
>> When running "make" I get this output:
>>    [ 68%] Building CXX object src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o
>>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In function 'std::string float_to_string(float)':
>>    /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:183: error: 'snprintf' was not declared in this scope
>>    make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/rtconversions.o] Error 1
>>    make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all] Error 2
>>    make: *** [all] Error 2
>
> This is strange, normally snprintf is declared in cstdio, can you make
> sure that it is? Maybe it is an gcc 4.4 compiler issue (i currently
> use gcc 4.3 and do not have the problem you are having)
>
>> Now using "make install" gives the same errors.
>
> That normal, make install tries to do make again since make failed.
>
>> In case it is important that the Xercers headers are found.
>> My .profile:
>>    # .bash_profile
>>    #needed for orocos:
>>    export LD_LIBRARY_PATH=$ACE_ROOT/lib:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/lib:$LD_LIBRARY_PATH
>>    ACE_ROOT=/home/bin/ACE_wrappers ; export ACE_ROOT
>>    TOA_ROOT=$ACE_ROOT/TAO; export TOA_ROOT
>>    JAVA_HOME=/opt/java/bin
>>    PATH=$PATH:$JAVA_HOME:/home/bin:/home/bin/xerces-c-3.0.1-x86-linux-gcc-3.4/bin
>>    export JAVA_HOME
>>    export PATH
>>
>> Output of ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-rtt-1.8.4:
>>    Orocos configure script.  WARNING: ONLY WORKS FOR GNULINUX INSTALLATIONS
>>    Invoking: '  /usr/bin/cmake ..  -DCMAKE_INSTALL_PREFIX=/home/bin/orocos/orocos-rtt-1.8.4'
>>    -- The C compiler identification is GNU
>>    -- The CXX compiler identification is GNU
>>    -- Check for working C compiler: /usr/bin/gcc
>>    -- Check for working C compiler: /usr/bin/gcc -- works
>>    -- Detecting C compiler ABI info
>>    -- Detecting C compiler ABI info - done
>>    -- Check for working CXX compiler: /usr/bin/c++
>>    -- Check for working CXX compiler: /usr/bin/c++ -- works
>>    -- Detecting CXX compiler ABI info
>>    -- Detecting CXX compiler ABI info - done
>>    Orocos RTT version  (1.8.4)
>>    Setting build type to 'RTT'
>>    -- Build type set to 'RTT' by user.
>>    -- Looking for Boost/C++ headers --
>>    -- Looking for Boost headers - found
>>    -- Looking for Xerces - headers not found
>>    CMAKE_VERSION: 2.6.4
>>    -- Detected gcc4: 4.4.0
>>
>>    -- Found Doxygen: /usr/bin/doxygen
>>    -- Found Doxygen -- API documentation can be built
>>    Disabling packaging for version 2.6
>>    -- Configuring done
>>    -- Generating done
>>    -- Build files have been written to: /home/Bas/Downloads/orocos-rtt-1.8.4/build
>>
>>    OK: configure done. Now issue 'make'.
>>
> This looks ok.
>
> Ruben
>

installation problem

On Aug 3, 2009, at 07:48 , b [dot] j [dot] burgers [..] ... wrote:

> Thanks for the quick response.
> I thought this wasn't the approprate place for these kind of
> questions, so didn't give much info, but seems it is.
>
> OS: 2.6.30-ARCH, arch linux (with KDEmod)
> GCC: 4.4.0 20090630 (prerelease)
> cmake version: 2.6-patch 4
>
> from /home/Bas/Downloads/orocos-rtt-1.8.4/build/ I run
> ../configure --with-gnulinux --prefix=/home/bin/orocos/orocos-
> rtt-1.8.4
>> From the output (at the bottum of the post) everything seems fine,
>> except that the Xercers headers are not found.
> When running "make" I get this output:
> [ 68%] Building CXX object src/CMakeFiles/orocos-rtt-
> dynamic_gnulinux.dir/os/rtconversions.o
> /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp: In
> function 'std::string float_to_string(float)':
> /home/Bas/Downloads/orocos-rtt-1.8.4/src/os/rtconversions.cpp:
> 183: error: 'snprintf' was not declared in this scope
> make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/os/
> rtconversions.o] Error 1
> make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_gnulinux.dir/all]
> Error 2
> make: *** [all] Error 2
> Now using "make install" gives the same errors.

Looks like you need to add "#include <stdio.h>" to the file /path/to/
rtt/src/os/rtconversions.cpp. The various GCC versions require
different header files, and we reguarly end up tweaking files for
these sort of issues.

HTH
Stephen

Getting started

On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
> I am trying to get started using OROCOS.
>
> I already found out that it is quite hard to find the right documentation
> and the best way to get started just by reading the orocos webpages.
>
> Would it make sense to document the problems I encounter,  so that the
> learning curve for new users could be made a little less steep?  I mean,  if
> I spend the effort to document this,  will anyone use this information to
> actually improve the documentation and/or add information to the website?
>

The idea is that 1. the wiki on the website should be the primary
resource for getting started and are maintained by users and
developers, the manuals (written in docbook-xml) are for reference and
written by developers. Feel free to create an account and play around
with the wiki!

Peter

Getting started

On Jul 17, 2009, at 11:27 , Peter Soetens wrote:

> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
>> I am trying to get started using OROCOS.
>>
>> I already found out that it is quite hard to find the right
>> documentation
>> and the best way to get started just by reading the orocos webpages.
>>
>> Would it make sense to document the problems I encounter, so that
>> the
>> learning curve for new users could be made a little less steep? I
>> mean, if
>> I spend the effort to document this, will anyone use this
>> information to
>> actually improve the documentation and/or add information to the
>> website?
>>
>
> The idea is that 1. the wiki on the website should be the primary
> resource for getting started and are maintained by users and
> developers, the manuals (written in docbook-xml) are for reference and
> written by developers. Feel free to create an account and play around
> with the wiki!

Ok, then how do we structure the Wiki help/tutorials/examples/getting-
started section? This same problem keeps cropping up and we've made
very little progress on it.

As a starting point (revived from previous discussions)

1. Get the FAQ out of XML and into the wiki so that it can be modified/
updated by all. Peter you hold the copyright, any problem with having
this move done for you?

2. Create a "getting started" page with pointers to downloading,
installing, and building basic hello world app (Peter's recent
"quicky" would be great for this). There are plenty of sites out there
with examples of this structure - OpenCV, Boost, etc. The installation
help in the online manuals is woefully out of date, and doesn't
include any of the new operating system we now support, nor new
package managers. Again, I suggest copy the existing XML code to wiki
pages and start updating that.

3. Tutorials/examples/help. This is hard to structure, but I am
*really* impressed with the Qt tutorials and examples. They are a
fabulous way to walk beginners through their code. I would recommend
copying their approach - focussed examples containing code and
explanations, as well as the complete source files (and add in
whatever CMake files are required to build). They also distinguish
tutorials from examples. A tutorial walks you through building a
complete application, in small, easily digestible steps. An example
shows you how to do one focussed thing. Orocos needs both.

4. Personally, I find the docbook-xml approach useless as a community
documentation effort. It is simply too hard to mod the file's, check
they build, generate a patch, send the patch, wait for the patch to be
committed, wait for the changed doc's to be built, and then finally
uploaded to the website. This takes way too long, compared to simply
updating a wiki. Now when it comes to the detailed documentation, like
the "Component Builders Manual", an actual document is probably better
than lots of wiki pages. This criticisim is more levelled at the
getting-started/installation/help kind of documention.

We have some suggestions on the Wiki from previous discucsions.

http://orocos.org/wiki/rtt/documentation-suggetsions

We, the community, have to move on this. Rather than throwing it back
at the newbies.

My 2c.
Stephen

Getting started

On Fri, Jul 17, 2009 at 17:56, S Roderick<kiwi [dot] net [..] ...> wrote:
> On Jul 17, 2009, at 11:27 , Peter Soetens wrote:
>
>> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
>>>
>>> I am trying to get started using OROCOS.
>>>
>>> I already found out that it is quite hard to find the right documentation
>>> and the best way to get started just by reading the orocos webpages.
>>>
>>> Would it make sense to document the problems I encounter,  so that the
>>> learning curve for new users could be made a little less steep?  I mean,
>>>  if
>>> I spend the effort to document this,  will anyone use this information to
>>> actually improve the documentation and/or add information to the website?
>>>
>>
>> The idea is that 1. the wiki on the website should be the primary
>> resource for getting started and are maintained by users and
>> developers, the manuals (written in docbook-xml) are for reference and
>> written by developers. Feel free to create an account and play around
>> with the wiki!
>
> Ok, then how do we structure the Wiki
> help/tutorials/examples/getting-started section? This same problem keeps
> cropping up and we've made very little progress on it.
>
> As a starting point (revived from previous discussions)
>
> 1. Get the FAQ out of XML and into the wiki so that it can be
> modified/updated by all. Peter you hold the copyright, any problem with
> having this move done for you?

I have no problem with any manual. The advantage of the docbook FAQ is
that it contained tags for question/answer pairs. Copying a docbook
document to mediawiki is time consuming.
Maybe this can help
http://wiki.blender.org/index.php/Meta:Tools/Wiki_conversions/DocBook_to...
?

>
> 2. Create a "getting started" page with pointers to downloading, installing,
> and building basic hello world app (Peter's recent "quicky" would be great
> for this). There are plenty of sites out there with examples of this
> structure - OpenCV, Boost, etc. The installation help in the online manuals
> is woefully out of date, and doesn't include any of the new operating system
> we now support, nor new package managers. Again, I suggest copy the existing
> XML code to wiki pages and start updating that.
>
> 3. Tutorials/examples/help. This is hard to structure, but I am *really*
> impressed with the Qt tutorials and examples. They are a fabulous way to
> walk beginners through their code. I would recommend copying their approach
> - focussed examples containing code and explanations, as well as the
> complete source files (and add in whatever CMake files are required to
> build). They also distinguish tutorials from examples. A tutorial walks you
> through building a complete application, in small, easily digestible steps.
> An example shows you how to do one focussed thing. Orocos needs both.
>
> 4. Personally, I find the docbook-xml approach useless as a community
> documentation effort. It is simply too hard to mod the file's, check they
> build, generate a patch, send the patch, wait for the patch to be committed,
> wait for the changed doc's to be built, and then finally uploaded to the
> website. This takes way too long, compared to simply updating a wiki. Now
> when it comes to the detailed documentation, like the "Component Builders
> Manual", an actual document is probably better than lots of wiki pages. This
> criticisim is more levelled at the getting-started/installation/help kind of
> documention.
>
> We have some suggestions on the Wiki from previous discucsions.
>
> http://orocos.org/wiki/rtt/documentation-suggetsions
>
> We, the community, have to move on this. Rather than throwing it back at the
> newbies.

I think you're right on target with all your points. There are however
also advantages with the docbook approach: It's versioned with the
sources; when we rename a class/function, we can rename it at once in
the docs as well; it can be used off-line. The thing I'm most afraid
of is the aging of wiki pages/online content. A pure mediawiki
installation is probably better than our drupal hack in terms of tool
support to do the editing job. I'll try to regain my enthusiasm which
I had when writing the original documentation and maintaining the
website. I admire your devotion :-)

Technically speaking and in my opinion, the best we could have is a
docbook backend (versioned with the sources), a mediawiki frontend and
a means to transfer the docbook to and from the server for local
versioning and editing.

Peter

Getting started

It is still not clear to me whether it makes sense to report my experiences
as a new orocos user, and if so where.

I had a look at the wiki. Here are my observations:

1. The link to the wiki is hard to find; I don't think the average newbie
will click it. The link "what is orocos?" looks much more attractive.

2. On the wiki main page, there are five links, all of which are either
cryptic (what is KDL, OCL or RTT?) or discouraging (wiki for site admins)
for a newbie. I went on and tried some links anyway.

3. KDL is a specific library. Since I am looking for basic information on
how orocos works and what it is useful for, I don't want to dive into a
specific library at this point.

4. OCL is a temporary page with hardly any useful information.

5. RTT leads to a page that does not even explain what RTT is.

It's not clear to me at this point what part of the wiki is supposed to be
useful to a newcomer.

What I am really looking for first is some basic information:

1. What is OROCOS?

It seems to be multiple things:
- a framework providing a mechanism to split a real-time control application
into more or less independent components
- some libraries of components using this mechanism

To get started, I want to first understand the mechanism.

The "What is OROCOS" page mentions 4 C++ libraries. It is not clear which
of these implements the mechanism. I guess its RTT?

2. How is OROCOS different from other ways to implement such applications?
Why or in what circumstances is it better? In other words, information
that allows me to judge early if OROCOS could be useful for my current
project.

3. Installation + a simple hello world so that I can understand the basic
mechanism of building something with OROCOS.

I know that someone installed OROCOS on my computer, but I don't know
where, or what to look for.

Other people will need more detailed instructions on how to download and
install it, on what platforms it works, ...

I am looking for -L -l and -I options needed to compile a simple
orocos-hello-world.

Plus maybe information on what kind of build environment I need to setup.
Cmake? Eclipse?

4. Some kind of tutorial.

A more experienced colleague pointed my to a kind of tutorial downloadable
from the website, explaining that it is quite hard to find. If it is hard
to find for an experienced user, how can a new user find it?

It's called rtt-exercises-1.8.1 and I am starting to read the README now.

Regards,
Johan

On Wed, Jul 22, 2009 at 12:30 PM, Peter Soetens <peter [..] ...>wrote:

> On Fri, Jul 17, 2009 at 17:56, S Roderick<kiwi [dot] net [..] ...> wrote:
> > On Jul 17, 2009, at 11:27 , Peter Soetens wrote:
> >
> >> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
> >>>
> >>> I am trying to get started using OROCOS.
> >>>
> >>> I already found out that it is quite hard to find the right
> documentation
> >>> and the best way to get started just by reading the orocos webpages.
> >>>
> >>> Would it make sense to document the problems I encounter, so that the
> >>> learning curve for new users could be made a little less steep? I
> mean,
> >>> if
> >>> I spend the effort to document this, will anyone use this information
> to
> >>> actually improve the documentation and/or add information to the
> website?
> >>>
> >>
> >> The idea is that 1. the wiki on the website should be the primary
> >> resource for getting started and are maintained by users and
> >> developers, the manuals (written in docbook-xml) are for reference and
> >> written by developers. Feel free to create an account and play around
> >> with the wiki!
> >
> > Ok, then how do we structure the Wiki
> > help/tutorials/examples/getting-started section? This same problem keeps
> > cropping up and we've made very little progress on it.
> >
> > As a starting point (revived from previous discussions)
> >
> > 1. Get the FAQ out of XML and into the wiki so that it can be
> > modified/updated by all. Peter you hold the copyright, any problem with
> > having this move done for you?
>
> I have no problem with any manual. The advantage of the docbook FAQ is
> that it contained tags for question/answer pairs. Copying a docbook
> document to mediawiki is time consuming.
> Maybe this can help
>
> http://wiki.blender.org/index.php/Meta:Tools/Wiki_conversions/DocBook_to...
> ?
>
> >
> > 2. Create a "getting started" page with pointers to downloading,
> installing,
> > and building basic hello world app (Peter's recent "quicky" would be
> great
> > for this). There are plenty of sites out there with examples of this
> > structure - OpenCV, Boost, etc. The installation help in the online
> manuals
> > is woefully out of date, and doesn't include any of the new operating
> system
> > we now support, nor new package managers. Again, I suggest copy the
> existing
> > XML code to wiki pages and start updating that.
> >
> > 3. Tutorials/examples/help. This is hard to structure, but I am *really*
> > impressed with the Qt tutorials and examples. They are a fabulous way to
> > walk beginners through their code. I would recommend copying their
> approach
> > - focussed examples containing code and explanations, as well as the
> > complete source files (and add in whatever CMake files are required to
> > build). They also distinguish tutorials from examples. A tutorial walks
> you
> > through building a complete application, in small, easily digestible
> steps.
> > An example shows you how to do one focussed thing. Orocos needs both.
> >
> > 4. Personally, I find the docbook-xml approach useless as a community
> > documentation effort. It is simply too hard to mod the file's, check they
> > build, generate a patch, send the patch, wait for the patch to be
> committed,
> > wait for the changed doc's to be built, and then finally uploaded to the
> > website. This takes way too long, compared to simply updating a wiki. Now
> > when it comes to the detailed documentation, like the "Component Builders
> > Manual", an actual document is probably better than lots of wiki pages.
> This
> > criticisim is more levelled at the getting-started/installation/help kind
> of
> > documention.
> >
> > We have some suggestions on the Wiki from previous discucsions.
> >
> > http://orocos.org/wiki/rtt/documentation-suggetsions
> >
> > We, the community, have to move on this. Rather than throwing it back at
> the
> > newbies.
>
> I think you're right on target with all your points. There are however
> also advantages with the docbook approach: It's versioned with the
> sources; when we rename a class/function, we can rename it at once in
> the docs as well; it can be used off-line. The thing I'm most afraid
> of is the aging of wiki pages/online content. A pure mediawiki
> installation is probably better than our drupal hack in terms of tool
> support to do the editing job. I'll try to regain my enthusiasm which
> I had when writing the original documentation and maintaining the
> website. I admire your devotion :-)
>
> Technically speaking and in my opinion, the best we could have is a
> docbook backend (versioned with the sources), a mediawiki frontend and
> a means to transfer the docbook to and from the server for local
> versioning and editing.
>
> Peter
>

Getting started

On Jul 17, 2009, at 11:56 , S Roderick wrote:

> On Jul 17, 2009, at 11:27 , Peter Soetens wrote:
>
>> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
>>> I am trying to get started using OROCOS.
>>>
>>> I already found out that it is quite hard to find the right
>>> documentation
>>> and the best way to get started just by reading the orocos webpages.
>>>
>>> Would it make sense to document the problems I encounter, so that
>>> the
>>> learning curve for new users could be made a little less steep? I
>>> mean, if
>>> I spend the effort to document this, will anyone use this
>>> information to
>>> actually improve the documentation and/or add information to the
>>> website?
>>>
>>
>> The idea is that 1. the wiki on the website should be the primary
>> resource for getting started and are maintained by users and
>> developers, the manuals (written in docbook-xml) are for reference
>> and
>> written by developers. Feel free to create an account and play around
>> with the wiki!
>
> Ok, then how do we structure the Wiki help/tutorials/examples/getting-
> started section? This same problem keeps cropping up and we've made
> very little progress on it.
>
> As a starting point (revived from previous discussions)
>
> 1. Get the FAQ out of XML and into the wiki so that it can be
> modified/
> updated by all. Peter you hold the copyright, any problem with having
> this move done for you?
>
> 2. Create a "getting started" page with pointers to downloading,
> installing, and building basic hello world app (Peter's recent
> "quicky" would be great for this). There are plenty of sites out there
> with examples of this structure - OpenCV, Boost, etc. The installation
> help in the online manuals is woefully out of date, and doesn't
> include any of the new operating system we now support, nor new
> package managers. Again, I suggest copy the existing XML code to wiki
> pages and start updating that.
>
> 3. Tutorials/examples/help. This is hard to structure, but I am
> *really* impressed with the Qt tutorials and examples. They are a
> fabulous way to walk beginners through their code. I would recommend
> copying their approach - focussed examples containing code and
> explanations, as well as the complete source files (and add in
> whatever CMake files are required to build). They also distinguish
> tutorials from examples. A tutorial walks you through building a
> complete application, in small, easily digestible steps. An example
> shows you how to do one focussed thing. Orocos needs both.
>
> 4. Personally, I find the docbook-xml approach useless as a community
> documentation effort. It is simply too hard to mod the file's, check
> they build, generate a patch, send the patch, wait for the patch to be
> committed, wait for the changed doc's to be built, and then finally
> uploaded to the website. This takes way too long, compared to simply
> updating a wiki. Now when it comes to the detailed documentation, like
> the "Component Builders Manual", an actual document is probably better
> than lots of wiki pages. This criticisim is more levelled at the
> getting-started/installation/help kind of documention.
>
> We have some suggestions on the Wiki from previous discucsions.
>
> http://orocos.org/wiki/rtt/documentation-suggetsions
>
> We, the community, have to move on this. Rather than throwing it back
> at the newbies.

I have posted a sample "Example" of the form and level of detail that
I think we need to provide to new users. Obviously, this is really
difficult and takes a lot of work to create these examples. I think
they are necessary, and I know many people who get invaluable help
from similar level-of-detail examples in other open-source projects
(eg Qt).

If we continue down this track, then I believe these examples should
go in the repository.

I also firmly believe that these examples should be buildable.
Providing just code without the means to build them, dramatically
decreases the value to the user. It puts simply another barrier in the
way of them trying out Orocos.

Thanks to Peter for his recent Quicky example, which forms the basis
for the build system here.

Feel free to observe, criticise, or change the provided example. I
have big shoulders ... :-)
Stephen

http://orocos.org/wiki/rtt/simple-examples/simple-tcp-client-using-non-b...

Getting started

OK. My point is that as a newbie, I did not get this information from
browsing through the website.

I did find The Orocos Component Builder's Manual which has a "Hello World"
example that seems very attractgive to a newbie at first sight, but there
is certainly not enough information there to actually get started.

Johan

On Fri, Jul 17, 2009 at 5:27 PM, Peter Soetens <peter [..] ...>wrote:

> On Fri, Jul 17, 2009 at 17:14, Johan Cockx<johan [..] ...> wrote:
> > I am trying to get started using OROCOS.
> >
> > I already found out that it is quite hard to find the right documentation
> > and the best way to get started just by reading the orocos webpages.
> >
> > Would it make sense to document the problems I encounter, so that the
> > learning curve for new users could be made a little less steep? I mean,
> if
> > I spend the effort to document this, will anyone use this information to
> > actually improve the documentation and/or add information to the website?
> >
>
> The idea is that 1. the wiki on the website should be the primary
> resource for getting started and are maintained by users and
> developers, the manuals (written in docbook-xml) are for reference and
> written by developers. Feel free to create an account and play around
> with the wiki!
>
> Peter
>