Orocos Real-Time Toolkit
Home Page: http://www.orocos.org
License: Other
In order to make a periodic tasks interval robust against system clock adjustments on gnulinux it makes sense to use CLOCK_MONOTONIC. This was already mentioned in http://bugs.orocos.org/show_bug.cgi?id=735.
My suggestion is to use CLOCK_MONOTONIC only in the rtos_task_set_period function (not in rtos_get_time_ns). So it should not cause any incompatibility issues with CLOCK_REALTIME. Is there any case this could lead to problems?
Diff:
diff --git a/rtt/os/gnulinux/fosi.h b/rtt/os/gnulinux/fosi.h
index 6e8fce7..567e19b 100644
--- a/rtt/os/gnulinux/fosi.h
+++ b/rtt/os/gnulinux/fosi.h
@@ -110,6 +110,19 @@ extern "C"
#endif
}
+ static inline NANO_TIME rtos_get_time_monotonic_ns( void )
+ {
+
+ TIME_SPEC tv;
+ clock_gettime(CLOCK_MONOTONIC, &tv);
+ // we can not include the C++ Time.hpp header !
+#ifdef __cplusplus
+ return NANO_TIME( tv.tv_sec ) * 1000000000LL + NANO_TIME( tv.tv_nsec );
+#else
+ return ( NANO_TIME ) ( tv.tv_sec * 1000000000LL ) + ( NANO_TIME ) ( tv.tv_nsec );
+#endif
+ }
+
/**
* This function should return ticks,
* but we use ticks == nsecs in userspace
diff --git a/rtt/os/gnulinux/fosi_internal.cpp b/rtt/os/gnulinux/fosi_internal.cpp
index c1355a7..b6091da 100644
--- a/rtt/os/gnulinux/fosi_internal.cpp
+++ b/rtt/os/gnulinux/fosi_internal.cpp
@@ -225,7 +225,7 @@ namespace RTT
// set period
mytask->period = nanosecs;
// set next wake-up time.
- mytask->periodMark = ticks2timespec( nano2ticks( rtos_get_time_ns() + nanosecs ) );
+ mytask->periodMark = ticks2timespec( nano2ticks( rtos_get_time_monotonic_ns() + nanosecs ) );
}
INTERNAL_QUAL void rtos_task_set_period( RTOS_TASK* mytask, NANO_TIME nanosecs )
@@ -244,11 +244,11 @@ namespace RTT
return 0;
// record this to detect overrun.
- NANO_TIME now = rtos_get_time_ns();
+ NANO_TIME now = rtos_get_time_monotonic_ns();
NANO_TIME wake= task->periodMark.tv_sec * 1000000000LL + task->periodMark.tv_nsec;
// inspired by nanosleep man page for this construct:
- while ( clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &(task->periodMark), NULL) != 0 && errno == EINTR ) {
+ while ( clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &(task->periodMark), NULL) != 0 && errno == EINTR ) {
errno = 0;
}
@@ -265,7 +265,7 @@ namespace RTT
else
{
TIME_SPEC ts = ticks2timespec( nano2ticks( task->period) );
- TIME_SPEC now = ticks2timespec( rtos_get_time_ns() );
+ TIME_SPEC now = ticks2timespec( rtos_get_time_monotonic_ns() );
NANO_TIME tn = (now.tv_nsec + ts.tv_nsec);
task->periodMark.tv_nsec = tn % 1000000000LL;
task->periodMark.tv_sec = ts.tv_sec + now.tv_sec + tn / 1000000000LL;
If one adds a callback with addEventPort, then the callback is called after start() as many times as new data arrived before the component was Running/start()'ed. This is due to how dataOnPort() is implemented in TaskContext.cpp .
This behavior can be reproduced by simple test
class MyService : public RTT::Service {
public:
MyService(TaskContext* owner) : Service("myservice", owner) {
cout << "MyService constructor." << endl;
}
~MyService() {
cout << "MyService destructor." << endl;
}
};
and then load myservice in any component and shutdown deployer.
It seems to be caused by boost::shared_ptr loop in RTT::Service definition (http://github.com/orocos-toolchain/rtt/blob/master/rtt/Service.hpp#L576):
typedef std::map< std::string, shared_ptr > Services;
Services services;
...
shared_ptr parent;
I tried installing orocos toolchain with xenomai 3.5 and 3.6 but non of them worked. so which version of xenomai is suitable with which version of orocos toolchain? i tried to install xenomai 2.6 in ubuntu 16.04 but some error is coming so i haven't tried it.
If I do the following in a freshly launched deployer:
Deployer [S]> var rt_string s
=
Deployer [S]> s="foo"
4.342 [ Warning][Logger] Conversion from string to rt_string
= foo
Deployer [S]> quit
The deployer segfaults:
TLSF bytes allocated=524288 overhead=6384 max-used=6432 currently-used=6432 still-allocated=48
Program received signal SIGSEGV, Segmentation fault.
0x00007f5251fdbb57 in boost::detail::sp_counted_impl_p<std::basic_string<char, std::char_traits<char>, RTT::os::rt_allocator<char> > >::dispose() ()
from /opt/orocos/hydro/lib/orocos/gnulinux/./types/librtt-typekit-gnulinux.so
(gdb) bt
#0 0x00007f5251fdbb57 in boost::detail::sp_counted_impl_p<std::basic_string<char, std::char_traits<char>, RTT::os::rt_allocator<char> > >::dispose() ()
from /opt/orocos/hydro/lib/orocos/gnulinux/./types/librtt-typekit-gnulinux.so
#1 0x00007f52560155b9 in boost::detail::shared_count::~shared_count() () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#2 0x00007f5251fdea1a in boost::function<std::basic_string<char, std::char_traits<char>, RTT::os::rt_allocator<char> > const& (std::string const&)>::~function() ()
from /opt/orocos/hydro/lib/orocos/gnulinux/./types/librtt-typekit-gnulinux.so
#3 0x00007f5251fdeb3f in RTT::types::TemplateConstructor<std::basic_string<char, std::char_traits<char>, RTT::os::rt_allocator<char> > const& (std::string const&)>::~TemplateConstructor() ()
from /opt/orocos/hydro/lib/orocos/gnulinux/./types/librtt-typekit-gnulinux.so
#4 0x00007f525609743e in RTT::types::TypeInfo::~TypeInfo() () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#5 0x00007f525609c9e0 in RTT::types::TypeInfoRepository::~TypeInfoRepository() () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#6 0x00007f525609dfa2 in boost::detail::sp_counted_impl_p<RTT::types::TypeInfoRepository>::dispose() () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#7 0x00007f525609ccc9 in boost::shared_ptr<RTT::types::TypeInfoRepository>::~shared_ptr() () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#8 0x00007f5254766d1d in __cxa_finalize (d=0x7f525631c050) at cxa_finalize.c:56
#9 0x00007f525600adb6 in __do_global_dtors_aux () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#10 0x00007fff3d67af40 in ?? ()
#11 0x00007fff3d67b230 in ?? ()
#12 0x00007f52560bfec1 in _fini () from /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.7
#13 0x00007fff3d67b230 in ?? ()
#14 0x00007f525632c92d in _dl_fini () at dl-fini.c:259
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I can reproduce this in OSX as well.
The patch from PR #35 effectively broke the use of a SlaveActivity without a master running an ExecutionEngine. The console and log file is filled with
44.685 [ FATAL ][uxvcos] SlaveActivity: cannot push messages to another engine, current engine is unsupported.
messages. The source is in SlaveActivity.cpp:187.
In my use case I have a custom main activity that controls the execution of all slave components, each of them running in a SlaveActivitiy. This main activity is the master of all slaves, but has no ExecutionEngine. Some slaves have event ports because I also use them in other deployments running in a non-periodic activity which requires triggering. Every write into such an event port prints the above log message.
Possible solutions:
Remove the log message and let SlaveActivity ignore triggers silently if no master activity is set as it was before.
I am aware of the problems this might cause for the original issue with blocking operation calls without a warning message. Perhaps as an alternative we could add a special handling in bool ExecutionEngine::process(DisposableInterface* c ) that directly queues the messages in the master's ExecutionEngine if available instead of taking them over later from the trigger() call? I will setup a pull request for this if it sounds reasonable to you.
Only allow an ExecutionEngine as master of SlaveActivities and clearly state that this is the only supported use case. This basically comes down to change the type of the mmaster member from base::RunnableInterface * to ExecutionEngine * and drop the dynamic_cast in trigger().
The problem seems to occure since the last commit by @smits.
After some samples are handled a corba exception is thrown:
34.326 [ ERROR ][Logger] caught CORBA exception while reading a remote channel: UNKNOWN UNKNOWN_UserException
and
omniORB: WARNING -- method 'read' raised an unexpected
std::exception (not a CORBA exception):
trying access the value inside an unset smart pointer
Travis supports OSX since some time, we might want to automate building PRs for OSX as well
From #129 (comment):
I am thinking about reverting this patch for toolchain-2.9 in favor of #138. #138 only provides a solution for the
Threadclass, but not forTimer.
Also it should be noted that both patches, #129 and #138, are not effective anymore for periodic components in connection with #91. So actually we would need a clean solution for all these cases of interruptible, perodic waiting by adding an OS abstraction of condition variables which support waiting based on a steady clock source. For gnulinux/pthread that would be using pthread_condattr_setclock with
CLOCK_MONOTONIC. And get rid of the semaphore inos::Timerby using a condition variable instead.
I would actually consider the fact that RTT cannot yet handle this correctly as a serious bug. I think the xenomai target does already use a monotonic clock source for time services, condition variables and semaphores, but not gnulinux and macosx.
Thoughts?
Today I stumbled across 94e3053, which added a preprocessor directive and switches to different implementations for atomic operations that are essential for lock-free buffer implementations.
I am not aware of the pros and cons of using the builtin intrinsics of gcc/clang compared to the custom platform-dependent implementations. But it would be worth to verify if Clang 3 and newer versions are still affected by the problem which triggered that patch back in 2011. I could not find any background information in the commit history, the Orocos forums or the old bug tracker.
From #154 (comment):
Could we remove the gcc version check completely? Does anyone still uses a gcc version older than 3.3, where the visibility support has been added?
If the compiler check in CMakeLists.txt would be removed, the value of the RTT_GCC_HASVISIBILITY cmake variable and preprocessor macro must be considered as true and removed from the generated header files.
I found the case when the promise is broken of OwnThread operations to be called in the thread safe way.
I have a task with sequential activity with OwnThread operations and event ports.
I found I can call OwnThread operations from task browser in the middle of update hook processing data from event port. I'd expect OwnThread operations to be serialized and called only after updateHook returned.
It's caused by SequentialActivity::thread() returning os::MainThread, so when operation is called from the main thread, OperationCallerInterface::isSend() returns false as the current thread matches activity thread even while activity is being triggered from another thread.
I don't know what would be the appropriate fix for this, OperationCallerInterface::isSend() should check the actual active sequential activity thread instead of the default MainThread, but I don't know how to do this in a thread safe way.
Another possible not very nice workarounds:
Hi, can one help me with how to unloadStateMachine when my component is in cleanupHook() state;
When I do
void TaskVilma::cleanupHook()
{
RTT::log(RTT::Warning) << "TaskVilma cleaning up !" << RTT::endlog();
scripting->stopStateMachine(state_machine_name_); // again in reactive mode, in final state
scripting->deactivateStateMachine(state_machine_name_); // deactivate state machine
scripting->unloadStateMachine(state_machine_name_); // unload state machine
recover(); // go to PreOperational state
}this block the component and lock the terminal.
There have been several request for better (or more visible) documentation of the cmake macros and functions in UseOROCOS-RTT.cmake and the variables set by the cmake configuration in orocos-rtt-config.cmake.
Here's d error:
In file included from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:50:0:
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/RTTCorbaConversion.hpp: In static member function ‘static bool RTT::corba::AnyConversionRTT::ConnPolicy::update(const CORBA::Any&, RTT::corba::AnyConversionRTT::ConnPolicy::StdType&)’:
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/RTTCorbaConversion.hpp:313:18: error: invalid initialization of non-const reference of type ‘const RTT::corba::CConnPolicy*&’ from an rvalue of type ‘const RTT::corba::CConnPolicy*’
if ( any >>= result ) {
^
In file included from /home/dinesh/ws/underlay_isolated/build_isolated/rtt/install/rtt/transports/corba/ServiceC.h:114:0,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTypeTransporter.hpp:44,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTemplateProtocol.hpp:42,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:49:
/home/dinesh/ws/underlay_isolated/build_isolated/rtt/install/rtt/transports/corba/DataFlowC.h:1320:32: note: initializing argument 2 of ‘CORBA::Boolean operator>>=(const CORBA::Any&, const RTT::corba::CConnPolicy*&)’
RTT_CORBA_API ::CORBA::Boolean operator>>= (const ::CORBA::Any &, const RTT::corba::CConnPolicy &);
^
In file included from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/DataFlowI.h:47:0,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/RemoteChannelElement.hpp:42,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTemplateProtocol.hpp:43,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:49:
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaConversion.hpp: In instantiation of ‘static bool RTT::corba::AnyConversion<std::vector<_Tp, _Alloc> >::update(const CORBA::Any&, RTT::corba::AnyConversion<std::vector<_Tp, _Alloc> >::StdType&) [with T = double; _Alloc = std::allocator; RTT::corba::AnyConversion<std::vector<_Tp, _Alloc> >::StdType = std::vector]’:
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTemplateProtocol.hpp:118:57: required from ‘bool RTT::corba::CorbaTemplateProtocol::updateFromAny(const CORBA::Any, RTT::base::DataSourceBase::shared_ptr) const [with T = std::vector; RTT::base::DataSourceBase::shared_ptr = boost::intrusive_ptrRTT::base::DataSourceBase]’
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:208:1: required from here
/home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaConversion.hpp:259:18: error: invalid initialization of non-const reference of type ‘const CORBA::DoubleSeq*&’ from an rvalue of type ‘const CORBA::DoubleSeq*’
if ( any >>= result ) {
^
In file included from /home/dinesh/ws/underlay_isolated/build_isolated/rtt/install/rtt/transports/corba/ServiceC.h:51:0,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTypeTransporter.hpp:44,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaTemplateProtocol.hpp:42,
from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:49:
/home/dinesh/ACE_wrappers/TAO/tao/AnyTypeCode/DoubleSeqA.h:86:41: note: initializing argument 2 of ‘CORBA::Boolean operator>>=(const CORBA::Any&, const CORBA::DoubleSeq*&)’
TAO_AnyTypeCode_Export ::CORBA::Boolean operator>>= (const ::CORBA::Any &, const CORBA::DoubleSeq *&);
^
In file included from /home/dinesh/ws/underlay_isolated/src/orocos/orocos_toolchain/rtt/rtt/transports/corba/CorbaLib.cpp:42:0:
/home/dinesh/ACE_wrappers/TAO/tao/PortableServer/PortableServer.h: At global scope:
/home/dinesh/ACE_wrappers/TAO/tao/PortableServer/PortableServer.h:34:1: warning: ‘TAO_Requires_POA_Initializer’ defined but not used [-Wunused-variable]
TAO_Requires_POA_Initializer = TAO_POA_Initializer::init ();
^
rtt/transports/corba/CMakeFiles/rtt-transport-corba-gnulinux_plugin.dir/build.make:62: recipe for target 'rtt/transports/corba/CMakeFiles/rtt-transport-corba-gnulinux_plugin.dir/CorbaLib.cpp.o' failed
make[2]: *** [rtt/transports/corba/CMakeFiles/rtt-transport-corba-gnulinux_plugin.dir/CorbaLib.cpp.o] Error 1
CMakeFiles/Makefile2:935: recipe for target 'rtt/transports/corba/CMakeFiles/rtt-transport-corba-gnulinux_plugin.dir/all' failed
make[1]: *** [rtt/transports/corba/CMakeFiles/rtt-transport-corba-gnulinux_plugin.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
<== Failed to process package 'rtt':
Command '['/home/dinesh/ws/underlay_isolated/install_isolated/env.sh', 'make', '-j4', '-l4']' returned non-zero exit status 2Reproduce this error by running:
==> cd /home/dinesh/ws/underlay_isolated/build_isolated/rtt && /home/dinesh/ws/underlay_isolated/install_isolated/env.sh make -j4 -l4Command failed, exiting.
AFtr i enter command "catkin_make_isolated --install -DENABLE_CORBA=ON -DCORBA_IMPLEMENTATION=TAO" i'm getting above error. I'm using ubuntu 16.04.
Background information: https://gcc.gnu.org/wiki/Visibility
A discussion related to #234 would be the state of hidden visibility support of Orocos RTT in general. By default RTT does not add the -fvisibility=hidden or -fvisibility-inlines-hidden compiler options, so unless this is done by the user, all symbols will be visible. The latter has been commented out in 7724f0d for some reason and never has been reactivated again since 2007.
I tried both options with Ubuntu Xenial and gcc 5.4.1 and the current toolchain-2.9 versions of RTT and OCL. Adding -fvisibility=hidden results in linker errors for the typekit and transport plugins. But -fvisibility-inlines-hidden works and only slightly reduces the size of the binaries, but cuts the length of the dynamic symbol table of liborocos-rtt-gnulinux.so by half. After stripping unneeded symbols from both libraries the size of the binary compiled with -fvisibility-inlines-hidden was only half of the one produced by a default build. For the RTT typekit plugin library the result is basically the same.
There have been quite some patches to the build config recently to set the GCC_HAS_VISIBILITY cmake flag and preprocessor macro for different compilers and actually it is probably not used at all (with the exception of some sparse explicit RTT_HIDE declarations) and a potential source of errors when creating patches without taking care of RTT_API declarations.
Is there anyone who is compiling RTT with non-default build options or who has experience with hidden visibility builds from before 2009?
We noticed an issue on input port since the big refactoring on toolchain 2.9.
If an input port is connected, but no data has ever been written, then the default sample is copied on read even if the FlowStatus is Nodata.
Here's a minimal test to highlight this issue :
#include <iostream>
#include <rtt/deployment/ComponentLoader.hpp>
#include <ocl/DeploymentComponent.hpp>
#include <rtt/TaskContext.hpp>
#include <rtt/InputPort.hpp>
#include <rtt/OutputPort.hpp>
#include <ocl/TaskBrowser.hpp>
#include <rtt/os/main.h>
using namespace RTT;
struct A : public TaskContext
{
A(const std::string& name):TaskContext(name){}
void updateHook()
{
// We initialize it at some random value
int_attr = 1234;
// We read from B, but B hasn't written anything yet.
FlowStatus f = port_int_in.read(int_attr);
// We expect 1234, but we get 0 !
std::cout << f<<" int --> "<<int_attr << std::endl;
}
InputPort<int> port_int_in;
int int_attr;
};
struct B : public TaskContext
{
B(const std::string& name):TaskContext(name){}
OutputPort<int> port_int_out;
};
int ORO_main(int argc, char** argv)
{
A a("a");
B b("b");
connectPeers(&a,&b);
a.port_int_in.connectTo(&b.port_int_out);
a.configure();
b.configure();
a.setActivity( new Activity(os::HighestPriority, 0.5 ) );
b.setActivity( new Activity(os::HighestPriority, 0.5 ) );
a.start();
b.start();
OCL::TaskBrowser browse( &a );
browse.loop();
return 0;
}when ever i try to build either the ros node with corba dependenci's or an orocos component. this both shows the same type of error ( similar ) i.e can't find rtt-transport-corba.. right now when i tried to build a rtt_gazebo_console package which i got from this link. i'm getting below error:
CMake Error at /home/robot/ws/underlay_isolated/install_isolated/lib/cmake/orocos-rtt/orocos-rtt-config.cmake:215 (message):
Could not find the following required OROCOS-RTT plugins:
rtt-transport-corba. You may want to append the plugins folder location to
the RTT_COMPONENT_PATH environment variable. E.g., if the plugin is
located at /path/to/plugins/libfoo-plugin.so, add /path/to to
RTT_COMPONENT_PATH
Call Stack (most recent call first):
CMakeLists.txt:6 (find_package)
I have used below scripts to build the package:
$ cd rtt_gazebo_console
$ mkdir build ; cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=$(pwd)/../../install
$ make install
this same script is working for the packages which don't depend on corba.
And similarly when i try to build the package with catkin_make. i'm getting below error:
CMake Error at /home/robot/ws/underlay_isolated/install_isolated/lib/cmake/orocos-rtt/orocos-rtt-config.cmake:215 (message):
Could not find the following required OROCOS-RTT plugins:
rtt-transport-corba. You may want to append the plugins folder location to
the RTT_COMPONENT_PATH environment variable. E.g., if the plugin is
located at /path/to/plugins/libfoo-plugin.so, add /path/to to
RTT_COMPONENT_PATH
Call Stack (most recent call first):
/home/robot/ws/underlay/devel/share/rtt_ros/cmake/rtt_ros-extras.cmake:3 (find_package)
rtt_gazebo_console/CMakeLists.txt:11 (use_orocos)
So what should i do to remove this error. How can i build this rtt_gazebo package with either cmake or catkin_make command
The catkin guys wrote this script, generate_cmake_rst.py, to generate RST documentation from CMake files.
I think this would be really helpful for people crafting Orocos CMake build scripts. If we wanted to use this, would it make sense to just copy the code into the RTT repo?
Then we could add it to the doc job too, right?
Hi there,
Yesterday I realized, that my zsh-env got screwed up as soon as the ros-kinetic-rtt package was installed:
> $ source /opt/ros/kinetic/setup.zsh
/opt/ros/kinetic/etc/catkin/profile.d/00.rtt.sh:10: command not found: grep
/opt/ros/kinetic/etc/catkin/profile.d/10.ros.sh:12: command not found: cat
/opt/ros/kinetic/etc/catkin/profile.d/99.roslisp.sh:4: command not found: cat
/opt/ros/kinetic/etc/catkin/profile.d/99.roslisp.sh:21: command not found: python
I nailed it down to the for loop of the file 00.rtt.sh
for path in echo $CMAKE_PREFIX_PATH | tr : ' ' "@CMAKE_INSTALL_PREFIX@"; do
Apparently path is reserved (or even equivalent) to PATH, so this for loop overwrites the PATH. Renaming the variable into anything else will solve the problem.
Hi,
compiling and testing orocos-rtt on a debian jessie box, I have found that
Start 7: corba-ipc-test
7/45 Test #7: corba-ipc-test ...................***Failed 0.06 sec
failed.
Where can I obtain a log file?
What should I have to check to find the fail?
When trying to build a very simple component I get this :
CMakeFiles/fbsched.dir/fbsched.cpp.o:(.data.rel.ro._ZTV7FBSched[_ZTV7FBSched]+0x118):
undefined reference to `RTT::TaskContext::prepareUpdateHook()'
collect2: error: ld returned 1 exit status
Same with ld or gold linker on gcc-5.
If i use clang the component builds fine but i can't import it :
/home/hoarau/lwr_ws/devel/lib/orocos/gnulinux/fbsched/libfbsched-gnulinux.so: undefined symbol: _ZNK3RTT11TaskContext11getPeerListEv
Building 2.8.1-rc1 I got this error:
[ 52%] Building CXX object rtt/scripting/CMakeFiles/rtt-scripting-xenomai_plugin.dir/SendHandleAlias.cpp.o
cd "/tmp/buildd/orocos-rtt-2.8.1rc1+dfsg/dbuild.xenomai/rtt/scripting" && /usr/bin/c++ -DOROCOS_TARGET=xenomai -DRTT_SCRIPTING_DLL_EXPORT -g -O2 -fstack-rc1+dfsg/rtt/typekit/RealTimeTypekitGlobals.cpp: In member function 'virtual bool RTT::types::RealTimeTypekitPlugin::loadGlobal
/tmp/buildd/orocos-rtt-2.8.1
/tmp/buildd/orocos-rtt-2.8.1rc1+dfsg/rtt/typekit/RealTimeTypekitGlobals.cpp:71:62: error: 'ORO_WAIT_ABS' was not declared in this scoperc1+dfsg/rtt/typekit/RealTimeTypekitGlobals.cpp:72:62: error: 'ORO_WAIT_REL' was not declared in this scope
globals->setValue( new Constant("ORO_WAIT_ABS", ORO_WAIT_ABS) );
^
/tmp/buildd/orocos-rtt-2.8.1
globals->setValue( new Constant("ORO_WAIT_REL", ORO_WAIT_REL) );
^
rtt/typekit/CMakeFiles/rtt-typekit-xenomai_plugin.dir/build.make:57: recipe for target 'rtt/typekit/CMakeFiles/rtt-typekit-xenomai_plugin.dir/RealTimeTypeki
make[4]: *** [rtt/typekit/CMakeFiles/rtt-typekit-xenomai_plugin.dir/RealTimeTypekitGlobals.cpp.o] Error 1
I always found difficult to catch errors and/or warnings in the deployer.
Is it possible to add colors to to the Logger ?
Like red for Error and yellow for Warning.
Two related questions I have after reading the compiler output.
Clang-3.5 on Linux will complain relatively often on using the macro:
...Plugin.cpp:51:1: warning: 'getRTTPluginName' has C-linkage specified, but returns user-defined type 'std::string' (aka 'basic_string<char, char_traits, allocator >') which is incompatible with C [-Wreturn-type-c-linkage]
I don't have an actual problem with that, it just looks not tidy ,-)
The state_test is currently failing in the master branch.
From https://travis-ci.org/orocos-toolchain/rtt/builds/33608293:
test 28
Start 28: state_test
28: Test command: /home/travis/ws_isolated/build_isolated/rtt/install/tests/state_test
28: Test timeout computed to be: 1500
28: Running 21 test cases...
28: /home/travis/ws_isolated/src/rtt/tests/state_test.cpp(1313): error in "testStateOperationSignalGuard": check sm->inState("FINI") failed
28: Dumping Service root
28: Attributes: ret(=0)
28: /home/travis/ws_isolated/src/rtt/tests/state_test.cpp(1553): error in "testStateEvents": Runtime error (inError() == true) encountered in StateMachine x in state INIT on line 40 of that StateMachine:
28: here > do test.assert( y1.inState("INIT") )
28:
28: Child Status: in child x.y1 in state ISPOSITIVE on line 21 of that StateMachine.
28: here > if (eb == true) then { do log("Local ISPOSITIVE->INIT Transition for b_event");} select INIT
28:
28: Dumping Service x
28: Attributes:
28:
28: *** 2 failures detected in test suite "Master Test Suite"
28/44 Test #28: state_test .......................***Failed 1.78 sec
I can reproduce this locally.
The librtt-typekit-gnulinux.so.2.7.0 fails to link when compiling the toolchain for the raspberrypi. The complete log file is attached.
Not sure why RealTimeTypekitGlobals.cpp keeps complaining when linking the library. Please note that the linking error only occurs when compiling under yocto project.
log.txt
Any ideas/help will be greatly appreciated. The problem is that I cannot see why except ld error and not sure why RealTimeTypekitGlobals.cpp.o keeps complaining about 'first defined here..' on linking.
The following code causes an error :
global void import_stuff()
{
import("rtt_ros") # creates "this.ros"
ros.import("test")
}deployer -s import_test.ops :
import_test.ops :Parse error at line 5: Service or Task "Deployer" has no Peer or Service ros (or Deployer was not found at all).
But this does not :
global void import_stuff()
{
import("rtt_ros")
scripting.eval("ros.import(\"test\")")
}Whenever a function ran into runScript, it does not accept newly created services/peers.
Why is it necessary to check for existing peers/services inside functions ?
The run {} program of an RTT State Machine is in v2.9 executed in the cycle after entry {} was executed. Previously, run {} was executed in the same cycle as entry {}, in case entry {} did not yield.
Put in another way, each cycle of an RTT State Machine now starts with executing the run {} program instead of first checking the transitions.
This has a major impact on event transitions. Since event transitions are ignored during entry {}, it is impossible to respond to event operations which would take one cycle after run {} to be processed (you can't put them in entry{} and they will be received too late when put in run{}). In addition, this also means that in this setting, a default transition would always be taken after run {} if the other transitions are all event transitions.
The issue was introduced because there was no clear documentation/formalism on when a StateMachine should go to sleep.
In order to restore the possibility, one could enable events already during entry {}, or allow users to specify in which cycle to execute run {}. This needs more thought.
Hi,
I'm writing this to have a visible documentation on the issue, the initial explanation including code to reproduce the issue was in a closed PR: #122, which was not a proper solution and raised other issues.
As output Ports are not buffered, all new data is dropped until the data was completely written to the connected input ports.
When a output port has two connections, new writes are only sent when the previous data was sent and the acks were received by corba. This is an issue on remote connections, especially on networks with low bandwidth.
When the low bandwith connection needs longer for the corba ack as the period of the Task, the next message will not be delivered at all. This means not even on the local connection received the message.
So if you connect a remote gui via network, local messages could possibly be lost.
Nevertheless, a simple workaround is to avoid using additional remote connections on output ports, this can be simply achieved by adding a repeater task, which just writes a data type received by an input port to an output port of the same type. This way only the repeater task is losing messages, not the important task with the double connections (original connection + repeater).
Currently, if a ServiceRequester is created with no owner TaskContext, it generates spurious warnings when connected to a subservice of the GlobalService:
Line 101 in f2090e1
The newest version of UseOROCOS-RTT.cmake broke the orocos_typegen_headers() macro and integration of typegen in general.
orocos_typegen_headers() macro generates the typekit and .orogen folders within the source directory. This is not a good idea as the same source folder could be used for multiple builds or different targets. Instead the typekit output directory should be set to somewhere relative to ${CMAKE_CURRENT_BINARY_DIR}.CMakeLists.txt file checks the IS_ROS_PACKAGE variable which is not defined in UseOROCOS-RTT.cmake anymore.add_library() instead of the orocos_typekit() macro and libraries end up in lib/ directly instead of lib/orocos/target/project/types. In general, typegen should use the orocos_* macros if available in order to use catkin-compatible output paths, too.orocos_generate_package() macro, the location of the generated pkg-config file for rosbuild does not fit anymore and should be replaced by the top-level CMAKE_SOURCE_DIR variable as the typekit subdirectory defines its own cmake project with project(...).A quick workaround for the rosbuild library paths would be to redefine IS_ROS_PACKAGE in UseOROCOS-RTT.cmake, but that still wouldn't solve the other issues or allow catkin devel-space builds.
first call:
0 im_filesystem_interface::getRosMsg im_filesystem_interface.cpp 116 0x7fb5f4541492
1 boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>::operator() mem_fn_template.hpp 49 0x7fb5f455d6c2
2 boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> >::operator()<im_pickit_msgs::FolderContent_<std::allocator<void> >, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list0> bind.hpp 243 0x7fb5f455cd39
3 boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> > >::operator() bind_template.hpp 20 0x7fb5f455c6a4
4 boost::detail::function::function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> > >, im_pickit_msgs::FolderContent_<std::allocator<void> > >::invoke function_template.hpp 132 0x7fb5f455bd9a
5 boost::function0<im_pickit_msgs::FolderContent_<std::allocator<void> > >::operator()() const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cbfdce
6 im_pickit_msgs::FolderContent_<std::allocator<void> > RTT::internal::LocalOperationCallerImpl<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::call_impl<int>() /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc593d
7 RTT::internal::InvokerImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > (), RTT::internal::LocalOperationCallerImpl<im_pickit_msgs::FolderContent_<std::allocator<void> > ()> >::call() /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc59c5
8 boost::fusion::result_of::invoke<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const>::type boost::fusion::invoke<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&) /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cae00d
9 void RTT::internal::RStore<im_pickit_msgs::FolderContent_<std::allocator<void> > >::exec<boost::_bi::bind_t<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_pickit_msgs::FolderContent_<std::allocator<void> > (*)(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&), boost::_bi::list2<boost::_bi::value<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::internal::InvokerBaseImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)()>, boost::_bi::value<boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > > > > >(boost::_bi::bind_t<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_pickit_msgs::FolderContent_<std::allocator<void> > (*)(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&), boost::_bi::list2<boost::_bi::value<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::internal::InvokerBaseImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)()>, boost::_bi::value<boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > > > >) /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc7ee8
10 RTT::internal::FusedMCallDataSource<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::evaluate() const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc8001
11 OCL::TaskBrowser::doPrint(boost::intrusive_ptr<RTT::base::DataSourceBase>, bool) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb64909f774
12 OCL::TaskBrowser::printResult(RTT::base::DataSourceBase*, bool) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490a035a
13 OCL::TaskBrowser::evalCommand(std::string&) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490a697a
14 OCL::TaskBrowser::loop() /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490acf49
15 main 0x40ee2c
second call (from RTT::base::DataSourceBase::getMember(std::string const&)):
0 im_filesystem_interface::getRosMsg im_filesystem_interface.cpp 116 0x7fb5f4541492
1 boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>::operator() mem_fn_template.hpp 49 0x7fb5f455d6c2
2 boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> >::operator()<im_pickit_msgs::FolderContent_<std::allocator<void> >, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list0> bind.hpp 243 0x7fb5f455cd39
3 boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> > >::operator() bind_template.hpp 20 0x7fb5f455c6a4
4 boost::detail::function::function_obj_invoker0<boost::_bi::bind_t<boost::_bi::unspecified, boost::_mfi::mf0<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_filesystem_interface>, boost::_bi::list1<boost::_bi::value<im_filesystem_interface*> > >, im_pickit_msgs::FolderContent_<std::allocator<void> > >::invoke function_template.hpp 132 0x7fb5f455bd9a
5 boost::function0<im_pickit_msgs::FolderContent_<std::allocator<void> > >::operator()() const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cbfdce
6 im_pickit_msgs::FolderContent_<std::allocator<void> > RTT::internal::LocalOperationCallerImpl<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::call_impl<int>() /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc593d
7 RTT::internal::InvokerImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > (), RTT::internal::LocalOperationCallerImpl<im_pickit_msgs::FolderContent_<std::allocator<void> > ()> >::call() /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc59c5
8 boost::fusion::result_of::invoke<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const>::type boost::fusion::invoke<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > >(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&) /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cae00d
9 void RTT::internal::RStore<im_pickit_msgs::FolderContent_<std::allocator<void> > >::exec<boost::_bi::bind_t<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_pickit_msgs::FolderContent_<std::allocator<void> > (*)(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&), boost::_bi::list2<boost::_bi::value<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::internal::InvokerBaseImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)()>, boost::_bi::value<boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > > > > >(boost::_bi::bind_t<im_pickit_msgs::FolderContent_<std::allocator<void> >, im_pickit_msgs::FolderContent_<std::allocator<void> > (*)(im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)(), boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > const&), boost::_bi::list2<boost::_bi::value<im_pickit_msgs::FolderContent_<std::allocator<void> > (RTT::internal::InvokerBaseImpl<0, im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::*)()>, boost::_bi::value<boost::fusion::cons<RTT::base::OperationCallerBase<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>*, boost::fusion::vector<boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> > > > >) /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc7ee8
10 RTT::internal::FusedMCallDataSource<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::evaluate() const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc8001
11 RTT::internal::FusedMCallDataSource<im_pickit_msgs::FolderContent_<std::allocator<void> > ()>::get() const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cb727e
12 RTT::types::StructTypeInfo<im_pickit_msgs::FolderContent_<std::allocator<void> >, false>::getMember(boost::intrusive_ptr<RTT::base::DataSourceBase>, std::string const&) const /home/intermodalics/pickit_ws_indigo/devel/lib/orocos/gnulinux/rtt_im_pickit_msgs/types/librtt-im_pickit_msgs-typekit-gnulinux.so 0x7fb611cc6267
13 RTT::base::DataSourceBase::getMember(std::string const&) /opt/ros/indigo/lib/liborocos-rtt-gnulinux.so.2.8 0x7fb649669552
14 OCL::TaskBrowser::doPrint(boost::intrusive_ptr<RTT::base::DataSourceBase>, bool) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb64909ff94
15 OCL::TaskBrowser::printResult(RTT::base::DataSourceBase*, bool) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490a035a
16 OCL::TaskBrowser::evalCommand(std::string&) /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490a697a
17 OCL::TaskBrowser::loop() /opt/ros/indigo/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 0x7fb6490acf49
18 main 0x40ee2c
From @meyerj in regard to the merge of PR jhu-lcsr-forks#10:
Just tested this rtt branch with a library package foo and an executable in package bar depending on foo using the
orocos_generate_package()/orocos_use_package()macros, as suggested by @smits. Compilation and execution were successful, but...This might be unrelated to this pull request. I noticed that the linker command lines generated by cmake are somewhat nasty:
/usr/bin/c++ -fPIC -Wl,-z,defs -shared -Wl,-soname,libfoo-gnulinux.so -o libfoo-gnulinux.so CMakeFiles/foo.dir/foo.cpp.o /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.6.0 -lboost_filesystem-mt -lboost_system-mt -lboost_serialization-mt -lpthread -lrt -ldl -Wl,-rpath,/opt/orocos/hydro/lib:::::::::::::::::::::::::::::::::::::::::: /usr/bin/c++ -Wl,-z,defs CMakeFiles/bar.dir/bar.cpp.o -o bar-gnulinux -rdynamic /tmp/foo/install/lib/libfoo-gnulinux.so /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so -lpthread -lrt /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.6.0 -lboost_filesystem-mt -lboost_system-mt -lboost_serialization-mt -lpthread -lrt -ldl -Wl,-rpath,/tmp/foo/install/lib:/opt/orocos/hydro/lib::::::::::::::::::::::::::::::::::::::::::
- The rpath contains multiple colons. Does somebody know where this option is coming from? I could not find a source in the Orocos RTT cmake scripts.
# foo/CMakeLists.txt cmake_minimum_required(VERSION 2.8.3) project(foo) find_package(OROCOS-RTT REQUIRED) include(${OROCOS-RTT_USE_FILE}) orocos_library(foo foo.cpp) orocos_generate_package()# bar/CMakeLists.txt cmake_minimum_required(VERSION 2.8.3) project(bar) find_package(OROCOS-RTT REQUIRED) include(${OROCOS-RTT_USE_FILE}) orocos_use_package(foo REQUIRED OROCOS_ONLY) orocos_executable(bar bar.cpp)# bar/CMakeCache.txt foo_orocos-rtt-gnulinux_LIBRARY:FILEPATH=/opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so
For reference:
https://github.com/orocos-toolchain/rtt/blob/master/rtt/transports/corba/CorbaDispatcher.hpp#L74
What this limit basically means is that if a component triggers more than 20 channels in one dispatch cycle (the simplest case being a single port that has more than 20 outbound connections), some will be lost.
I could probably figure out a fix for this, but I'm not sure what the best way would be. The two fixes I see right now are:
I would personally favor (2) as it would be in line with the ability to explicitly choose a dispatcher at connection time, a pet feature of mine (thus allowing to create connection domains and isolate connections to each other - as e.g. GUI vs. in-robot or wifi vs. wired)
From @meyerj in regard to the merge of PR jhu-lcsr-forks#10:
Just tested this rtt branch with a library package foo and an executable in package bar depending on foo using the
orocos_generate_package()/orocos_use_package()macros, as suggested by @smits. Compilation and execution were successful, but...This might be unrelated to this pull request. I noticed that the linker command lines generated by cmake are somewhat nasty:
/usr/bin/c++ -fPIC -Wl,-z,defs -shared -Wl,-soname,libfoo-gnulinux.so -o libfoo-gnulinux.so CMakeFiles/foo.dir/foo.cpp.o /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.6.0 -lboost_filesystem-mt -lboost_system-mt -lboost_serialization-mt -lpthread -lrt -ldl -Wl,-rpath,/opt/orocos/hydro/lib:::::::::::::::::::::::::::::::::::::::::: /usr/bin/c++ -Wl,-z,defs CMakeFiles/bar.dir/bar.cpp.o -o bar-gnulinux -rdynamic /tmp/foo/install/lib/libfoo-gnulinux.so /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so -lpthread -lrt /opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so.2.6.0 -lboost_filesystem-mt -lboost_system-mt -lboost_serialization-mt -lpthread -lrt -ldl -Wl,-rpath,/tmp/foo/install/lib:/opt/orocos/hydro/lib::::::::::::::::::::::::::::::::::::::::::
liborocos-rtt-gnulinux.so.2.6.0 is coming from the find_package(OROCOS-RTT) line in package bar's CMakeLists.txt (as in package foo) and liborocos-rtt-gnulinux.so from the pkg-config dependency between orocos-rtt-gnulinux and foo-gnulinux:# foo/CMakeLists.txt cmake_minimum_required(VERSION 2.8.3) project(foo) find_package(OROCOS-RTT REQUIRED) include(${OROCOS-RTT_USE_FILE}) orocos_library(foo foo.cpp) orocos_generate_package()# bar/CMakeLists.txt cmake_minimum_required(VERSION 2.8.3) project(bar) find_package(OROCOS-RTT REQUIRED) include(${OROCOS-RTT_USE_FILE}) orocos_use_package(foo REQUIRED OROCOS_ONLY) orocos_executable(bar bar.cpp)# bar/CMakeCache.txt foo_orocos-rtt-gnulinux_LIBRARY:FILEPATH=/opt/orocos/hydro/lib/liborocos-rtt-gnulinux.so
Following code does not work as expected in toolchain-2.9.
Component A:
vector<double> v(10, 0.0);
out_port.setDataSample(v);
Component B:
vector<double> v;
in_port.getDataSample(v);
cout << "size = " << v.size();
Output is "size = 0" instead of "size = 10". The problem persists if complex data type such as sensor_msg::JointState is used instead of vector.
It seems that problem was introduced by one of the latest commits, because year old version of toolchain-2.9 works fine.
In the attachment is test component for vector and sensor_msg::JointState datatypes.
test_samples.zip
Like the connect in Qt, I think it would be useful to be able to connect an operationCaller to multiple operations.
A provides reset()
B provides reset() # B is a different component
connectServices("A","C")
connectServices("B","C")
C.reset() # calls A.reset() and B.reset()
That would only be allowed for operations that have no return of course.
I'm getting the following error:
In file included from /Users/rubensmits/orocos_ws/src/orocos_toolchain/rtt/rtt/typekit/RealTimeTypekitTypes.cpp:42:
In file included from /Users/rubensmits/orocos_ws/src/orocos_toolchain/rtt/rtt/typekit/Types.inc:5:
In file included from /Users/rubensmits/orocos_ws/src/orocos_toolchain/rtt/rtt/typekit/../internal/DataSource.hpp:42:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/string:1687:23: error:
'operator=' is a private member of 'RTT::os::rt_allocator<char>'
__alloc() = __str.__alloc();
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~
/Users/rubensmits/orocos_ws/src/orocos_toolchain/rtt/rtt/typekit/Types.inc:52:21: note: in
instantiation of member function 'std::__1::basic_string<char, std::__1::char_traits<char>,
RTT::os::rt_allocator<char> >::__copy_assign_alloc' requested here
template class std::basic_string<char, std::char_traits<char>, RTT::os::rt_allocator<char> >;
^
/Users/rubensmits/orocos_ws/src/orocos_toolchain/rtt/rtt/typekit/../internal/../os/oro_allocator.hpp:307:14: note:
declared private here
void operator=(const rt_allocator&);
^
Since orocos relies on pkg-config to determine products of dependencies, two orocos packages cannot be built in a single catkin build pass.
We have a few options:
I'm leaning towards option 3. What are other people's thoughts?
Hi,
i have in fact two questions:
a) what is the difference between this two projects? Are they related?
https://github.com/orocos-toolchain
and
https://github.com/orocos
b) What is the general state of the Project? Is it now nearly integrated in ROS? I see current development on this Project but the official documentation www.orocos.org seems way out of date.
I would like to use orocos as a framework for an application but i am not sure about it's status.
The following ops code from the orocos component manual [1] does not work because of inline comments. It can be fixed with ';' at the end of each statement. But finally the code below should not throw an error.
require("print") // test
print.ln("Script imported HelloWorld package:") //
displayComponentTypes()
loadComponent("Hello", "OCL::HelloWorld")
print.ln("Script created Hello Component with period: " + Hello.getPeriod() )
Error message:
[ ERROR ][ScriptingService] helloworld.ops :Parse error at line 2: Syntactic error: End of statement expected. Use a newline or ';' to separate statements.
I have a task with periodic activity created in updateHook():
bool Task::configureHook()
{
setActivity(new RTT::Activity(ORO_SCHED_RT, m_cfg.priority, m_cfg.period));
return true;
}
task.start();
....
task.stop(); task.configure(); task.start()
It always segfaults, looks like the activity loop continues to use the old activity data, deleted when the new Activity created. I tested with the current toolchain 2.9, but can reproduce the it with older versions as well.
Valgrind output:
==27410== Thread 7:
==27410== Invalid read of size 8
==27410== at 0x6266C1C: RTT::os::MutexLock::MutexLock(RTT::os::MutexInterface&) (MutexLock.hpp:63)
==27410== by 0x795865B: RTT::Activity::loop() (Activity.cpp:211)
==27410== by 0x79681B0: RTT::os::thread_function(void*) (Thread.cpp:100)
==27410== by 0x796CA0F: RTT::os::rtos_posix_thread_wrapper(void*) (fosi_internal.cpp:99)
==27410== by 0x96F4181: start_thread (pthread_create.c:312)
==27410== by 0xA22447C: clone (clone.S:111)
==27410== Address 0xe625180 is 256 bytes inside a block of size 368 free'd
==27410== at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==27410== by 0x7958267: RTT::Activity::~Activity() (Activity.cpp:110)
==27410== by 0x79051DD: void boost::checked_delete<RTT::base::ActivityInterface>(RTT::base::ActivityInterface*) (checked_delete.hpp:34)
==27410== by 0x7918547: boost::detail::sp_counted_impl_p<RTT::base::ActivityInterface>::dispose() (sp_counted_impl.hpp:78)
==27410== by 0x5FA7301: boost::detail::sp_counted_base::release() (sp_counted_base_gcc_x86.hpp:146)
==27410== by 0x5FA73C4: boost::detail::shared_count::~shared_count() (shared_count.hpp:371)
==27410== by 0x78FD6E9: boost::shared_ptr<RTT::base::ActivityInterface>::~shared_ptr() (shared_ptr.hpp:328)
==27410== by 0x78FEB91: boost::shared_ptr<RTT::base::ActivityInterface>::reset() (shared_ptr.hpp:619)
==27410== by 0x78FCA56: RTT::TaskContext::setActivity(RTT::base::ActivityInterface*) (TaskContext.cpp:350)
==27410== by 0x17F24A70: Task::configureHook()
I noticed in a few travis build that the slavetest sometimes failes:
The patch cb4a376, which is part of PR #91, revealed a principal problem of the current implementation of SlaveActivity and was therefore reverted in d04b1e9.
It is not clear to me what is the difference between a SlaveActivity which has a master activity and one which does not. According to documentation in SlaveActivity.hpp:
* Any activity object can be a master of a SlaveActivity,
* including itself. A master needs to keep track of its slave
* itself. There is no standard mechanism in RTT in which masters
* execute slaves. You need to code this yourself in your master
* activity by calling execute() on each Slave.
So the member variable mperiod should be completely unused in case mmaster is set. This is what motivated the "bugfix" in cb4a376.
What does "including itself" mean in this context? I think the current implementation does not allow this and if it would, there were indefinite recursions. What was probably meant here is that a SlaveActivity can be the master of another SlaveActivity.
There is no automatic mechanism that keeps track of slave instances of an activity and that would notify them if their master is destroyed. As a consequence, it is the full responsibility of the user not only to execute the slaves, but also to make sure that the component which owns the master activity is not destroyed before the last slave, that still has a pointer. Otherwise calls to some member functions of the slave activity cause segfaults. Without cb4a376 the mmaster pointer was not accessed during the destruction of the slave, but checking the internal mperiod member only is not consistent with the previous item.
Unlike Activity, stopping the SlaveActivity asynchronously (e.g. from the main thread during cleanup) does not wait for the successful completion of the cycle, even if breakLoop() returned true.
I wonder whether there is a way to completely avoid that the slave activity has to know whether it is executed periodically or not. Actually there is no guarantee that the master executes all slaves periodically anyway, even if the master itself has a periodic activity.
Hi everybody,
While compiling Orocos RTT, I encountered an error that I do not know how to fix.
user@NRMKStep-PC:~/dev/orocos/orocos-2.8/build/rtt$ make
[ 0%] Building CXX object rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/Operation.cpp.o
[ 0%] Building CXX object rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/FactoryExceptions.cpp.o
[ 1%] Building CXX object rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/ConfigurationInterface.cpp.o
In file included from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/DataSourceTypeInfo.hpp:44:0,
from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/DataSource.inl:5,
from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/DataSource.hpp:237,
from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/Attribute.hpp:42,
from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/ConfigurationInterface.hpp:44,
from /home/user/dev/orocos/orocos-2.8/build/rtt/rtt/ConfigurationInterface.cpp:40:
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:99:48: error: expected ‘)’ before ‘<’ token
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:165:41: error: ‘array’ is not a member of ‘boost::serialization’
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:165:41: note: suggested alternative:
/usr/local/include/boost/array.hpp:60:11: note: ‘boost::array’
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:165:75: error: expected primary-expression before ‘>’ token
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:165:77: error: expected primary-expression before ‘const’
/home/user/dev/orocos/orocos-2.8/build/rtt/rtt/internal/../types/carray.hpp:165:89: error: declaration of ‘operator=’ as non-function
make[2]: *** [rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/ConfigurationInterface.cpp.o] Error 1
make[1]: *** [rtt/CMakeFiles/orocos-rtt-gnulinux_dynamic.dir/all] Error 2
make: *** [all] Error 2
I seemed to me that there was something wrong between RTT and Boost. Also, I tried many Boost versions but the errors were same.
I really appreciate if somebody can give me an advice how to solve my problem.
Thank you.
When I import a component from an overlay workspace it always takes the last on the ROS_PACKAGE_PATH list. The order of priority is reversed !
if I load component A (import("A")) it will output :
# blabla loading from component A from workspace2 --> success !
# but then, loading component A from workspace 1 (why ??) --> success
[ Warning][ComponentLoader::import(path_list)] Component type name A already used: overriding.This seems to be the culprit.
From #26:
So what if we make it so calling orocos_generate_package() and catkin_package() mutually exclusive, and then always install package-$OROCOS_TARGET.pc and package.pc with identical contents so that the CMake variables don't get overwritten?
This will make the policy for using orocos_generate_package() with catkin very explicit, and I don't think we lose any functionality which can't be achieved by creating a pair of packages (one catkin and one orocos).
I would prefer an "empty" file that just has the Name:, Description: and Version: field. I am thinking at the use case where different build folders with different Orocos targets share the same devel- or install-space that contain the binaries and pkg-config files. Whoever relies on the .pc-files without the target name appended should not see the include directories and libraries depending on which target has been built last.
Or we only create this file if the target is gnulinux (or OROCOS_DEFAULT_TARGET if defined...) and add one additional Requires: ${PACKAGE_NAME}-gnulinux line to delegate to the target-specific pkg-config file. This would fix issues with rosbuild and also enable usage of rospack command line tools for Orocos packages as long as only the gnulinux target is used.
I think there's a regression in the 2.9 branch :
require("print")
global void hello()
{
print.log(Warning,"Hi!")
}
global void test()
{
hello()
}deployer -s bug.ops
This code stops the execution (deployer is stuck somewhere, no crash) on the 2.9 branch. Same with :
require("print")
global void hello()
{
print.log(Warning,"Hi!")
}
hello()Same if the function should be called directly.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.