The following error occurs after trying to build eCAL with ECAL_THIRDPARTY_BUILD_TINYXML2=OFF with the commit cfdfcd2. In previous versions, it used to work fine. The workaround is to set ECAL_THIRDPARTY_BUILD_TINYXML2 to on or leave it by default.

CMake Error at CMakeLists.txt:284 (_find_package):
  By not providing "Findtinyxml2.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "tinyxml2",
  but CMake did not find one.

tinyxml2Config.cmake
tinyxml2-config.cmake

  Add the installation prefix of "tinyxml2" to CMAKE_PREFIX_PATH or set
 "tinyxml2_DIR" to a directory containing one of the above files.  If
 "tinyxml2" provides a separate development package or SDK, be sure it has
 been installed.
Call Stack (most recent call first):
  app/sys/sys_core/CMakeLists.txt:24 (find_package)

-- Configuring incomplete, errors occurred!

Hello!

I've built eCAL 5.7.1 with iceoryx with the following cmake command:
cmake .. -DCMAKE_BUILD_TYPE=Release -DECAL_THIRDPARTY_BUILD_PROTOBUF=ON -DECAL_THIRDPARTY_BUILD_CURL=OFF -DECAL_THIRDPARTY_BUILD_HDF5=ON -DHAS_CAPNPROTO=ON -DBUILD_APPS=OFF -DBUILD_SAMPLES=ON -DBUILD_TIME=ON -DECAL_LAYER_ICEORYX=ON

Running ecal_sample_latency_snd and ecal_sample_latency_rec_cb along with RouDi give fine results, however, the samples running multiple instances of subscribers produce the following output:

publisher:

sudo ./ecal_sample_multiple_snd
CUDPSender: Setting TTL failed: Invalid argument
CUDPSender: Setting TTL failed: Invalid argument
2020-09-30 17:11:01.161 [ Info  ]: Application registered management segment 0x7f5d3e8000 with size 113341568 to id 1
2020-09-30 17:11:01.161 [ Info  ]: Application registered payload segment 0x7f39c39000 with size 595259200 to id 2
...
pub  109:       3199 Msg/s
pub  110:       3199 Msg/s
pub  111:       3199 Msg/s
pub  112:       3199 Msg/s
pub  113:       3199 Msg/s
pub  114:       3199 Msg/s
pub  115:       3199 Msg/s
...
Sum:          639964  Msg/s
Sum:             639 kMsg/s
Sum:               0 MMsg/s

receiver:

./ecal_sample_multiple_rec_cb
CUDPSender: Setting TTL failed: Invalid argument
CUDPSender: Setting TTL failed: Invalid argument
create subscribers ..
2020-09-30 17:10:53.850 [ Info  ]: Application registered management segment 0x7f693e8000 with size 113341568 to id 1
2020-09-30 17:10:53.851 [ Info  ]: Application registered payload segment 0x7f45c39000 with size 595259200 to id 2
...
sub  109:          0 Msg/s
sub  110:          0 Msg/s
sub  111:          0 Msg/s
sub  112:       3199 Msg/s
sub  113:          0 Msg/s
sub  114:          0 Msg/s
sub  115:          0 Msg/s
...
Sum:            3200  Msg/s
Sum:               3 kMsg/s
Sum:               0 MMsg/s

I suppose all subscribers should receive the corresponding message, not just one. I tried to run an other sample code:

// create 2 publishers
eCAL::CPublisher pub1("foo1", "std::string");
eCAL::CPublisher pub2("foo2", "std::string");
 
// sending "hello world" on 2 different topics
while(eCAL::Ok())
{
  pub1.Send("hello");
  eCAL::Process::SleepMS(1000);
  pub2.Send("world");
}

// define a subscriber callback function
void OnReceive(const char* topic_name_, const std::string& message_)
{
  printf("We received %s on topic %s\n.", message_.c_str(), topic_name_);
}
 
// create 2 subscriber
eCAL::string::CSubscriber sub1("foo1");
eCAL::string::CSubscriber sub2("foo2");
 
// register subscriber callback function
auto callback = std::bind(OnReceive, std::placeholders::_1, std::placeholders::_2);
sub1.AddReceiveCallback(callback);
sub2.AddReceiveCallback(callback);
 
// idle main thread
while(eCAL::Ok())
{
  // sleep 100 ms
  std::this_thread::sleep_for(std::chrono::milliseconds(100));
}

In this case, only sub2 is triggered, given 'foo2' in the output. Swapping sub1 declaration with sub2, output will change to 'foo1'. In case of even more subscribers, only the last declarated one triggers.
However, splitting each subscriber into different processes, and running parallel each, everything works as they meant to be. But I need to have them all in one process.

The ecal.ini file(s) were left as default, having:

network_enabled= true
inproc_rec_enabled= true
shm_rec_enabled= true
udp_mc_rec_enabled= true
npcap_enabled= false
use_inproc=0
use_shm=2
use_udp_mc=2

Anyways, if I change ecal.ini content, the situation above still exists.

If so, what am I doing wrong? I would appreciate if anyone could help me with this issue.

The current MSI installer does not include Protobuf. Thus it is not possible on Windows to link agains eCAL, when using the official builds.

I was wondering if ECAL has ever been compiled and tested on Android. I did a search and found some info on android https://github.com/continental/ecal/search?q=android&unscoped_q=android. However I'm not sure if that really indicates support. I was wondering if it would be possible to make an android app that can subscribe to topics and services being published on a local network. Similar to how ROS is supported on Android.

If it's not currently possible, I was wondering if it was something on the roadmap for ECAL.

Thanks!

There seems to be only one example of using the eCAL python wrapper with Services. However it is only passing strings (looks like its encoding a string as ascii bytes). It would be nice if there was an example using Protobuf as we have for Publish and Subscribe.

My guess, not sure, is that we currently have to manually serialize our Protobuff request objects as bytes and then on the receiving end deserialize them back. Similarly with the response object.

Describe the bug
I have build ECAL and then installed it using cpack and dpkg successfully with no errors. Note that I installed protobuf using apt-get as shown in the README. My OS is ubuntu 18.04. I then create a simple package using CMake with a CMakeLists.txt file that that simply has find_package(eCAL REQUIRED). However an error is generated:

CMake Error at /usr/lib/cmake/eCAL/eCALConfig.cmake:72 (find_package):
  By not providing "Findprotobuf.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "protobuf",
  but CMake did not find one.

  Could not find a package configuration file provided by "protobuf" with any
  of the following names:

    protobufConfig.cmake
    protobuf-config.cmake

  Add the installation prefix of "protobuf" to CMAKE_PREFIX_PATH or set
  "protobuf_DIR" to a directory containing one of the above files.  If
  "protobuf" provides a separate development package or SDK, be sure it has
  been installed.
Call Stack (most recent call first):
  CMakeLists.txt:16 (find_package)


-- Configuring incomplete, errors occurred!
See also "/opt/workspace/build/CMakeFiles/CMakeOutput.log".
See also "/opt/workspace/build/CMakeFiles/CMakeError.log".

Here is the file, /usr/lib/cmake/eCAL/eCALConfig.cmake, which is installed by the dpkg that is causing the issue:

root@0df59812fc9c:/opt/workspace/build# cat /usr/lib/cmake/eCAL/eCALConfig.cmake 
# ========================= eCAL LICENSE =================================
#
# Copyright (C) 2016 - 2019 Continental Corporation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# 
#      http://www.apache.org/licenses/LICENSE-2.0
# 
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
# ========================= eCAL LICENSE =================================


####### Expanded from @PACKAGE_INIT@ by configure_package_config_file() #######
####### Any changes to this file will be overwritten by the next CMake run ####
####### The input file was eCALConfig.cmake.in                            ########

get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)

macro(set_and_check _var _file)
  set(${_var} "${_file}")
  if(NOT EXISTS "${_file}")
    message(FATAL_ERROR "File or directory ${_file} referenced by variable ${_var} does not exist !")
  endif()
endmacro()

macro(check_required_components _NAME)
  foreach(comp ${${_NAME}_FIND_COMPONENTS})
    if(NOT ${_NAME}_${comp}_FOUND)
      if(${_NAME}_FIND_REQUIRED_${comp})
        set(${_NAME}_FOUND FALSE)
      endif()
    endif()
  endforeach()
endmacro()

####################################################################################

# Set some build relevant variables to build samples appropriately
set(ECAL_LAYER_FASTRTPS      "OFF")
set(eCAL_install_samples_dir "bin")

set(eCAL_VERSION_MAJOR  5)
set(eCAL_VERSION_MINOR  5)
set(eCAL_VERSION_PATCH  1)
set(eCAL_VERSION_STRING 5.5.1)

# eCAL is provided only with Release and Debug Version, thus map the other configs to Release build.
set(CMAKE_MAP_IMPORTED_CONFIG_MINSIZEREL Release)
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release)

include("${PACKAGE_PREFIX_DIR}/lib/cmake/eCAL/helper_functions/ecal_add_functions.cmake")
include("${PACKAGE_PREFIX_DIR}/lib/cmake/eCAL/helper_functions/ecal_helper_functions.cmake")
include("${PACKAGE_PREFIX_DIR}/lib/cmake/eCAL/helper_functions/ecal_install_functions.cmake")
include("${PACKAGE_PREFIX_DIR}/lib/cmake/eCAL/eCALTargets.cmake")

# careful, this is a Windows hack to find protobuf etc. with the eCAL installation
# To be removed if there is a better solution like Conan e.g.
if(WIN32)
  list(APPEND CMAKE_MODULE_PATH "${PACKAGE_PREFIX_DIR}/../../../../cmake")
  list(APPEND CMAKE_PREFIX_PATH "${PACKAGE_PREFIX_DIR}/../../../../cmake")
endif()

find_package(CMakeFunctions REQUIRED)
# PROBLEM IS HERE
find_package(protobuf REQUIRED)
find_package(Threads REQUIRED)

To Fix

To fix the issue all I had to do was change the lower case p in protobuf to a capital P. Basically:

find_package(Protobuf REQUIRED)

All errors go away and everything is working.

eCAL should use Travis CI to check builds for all supported platforms.

Hello,

not a real issue, more a suggestion.

I created an initial high-level interface for my personal GO home automation eCAL needs based on a low-level interface auto-generated by SWIG. It's not rocket science, but maybe you want to provide an example SWIG i-File with your documentation as it may help people to call eCAL from a wide variety of languages (like Ruby, Lua, Javascript - see "Exits" on their homepage).

The file I used resides here. The paths are based on an eCAL installation from the AUR on Arch Linux.

Best regards,

Tobias

Is your feature request related to a problem? Please describe.
Python is besides C++ one of the most popular languages in the areas of AI and robotics. The eCAL python binding (with the power of the included python batteries) would open a wide range of additional use cases.

Describe the solution you'd like
Wrap eCAL's C++ API as python extension. We need to find a gentle way how to bring in the python binding generation in the existing CMake based build and how to deploy for different targets / different python versions.

Describe alternatives you've considered
No alternatives ..

I was wondering if it was possible for a single publisher to:

1. Use Shared Memory for other processes on the same host that are subscribing
2. Use UDP Multicast for other processes that are on different hosts that are subscribing.

I'm just not sure if this is taken care of automatically (or possible!)

In the elif block for ECAL_OS_QNX at line 961 of ecal_process.cpp, there is a missing declaration for argument_vector, std::vector<std::string> argument_vector; as it appears in every other case. Please add that missing line under g_process_par = "";.

This is more of a support request than a feature or bug request. If this is not the right forum for this discussion let me know.

I am having trouble setting up getting UDP Multicast to work across hosts. I have followed the instructions as documented in the README. I am able to get it to work on the same host (HOST1):
.

However when I try to set it up ECAL on another computer (HOST2, same local home network), ecal_mon is not able to see the published messages being broadcast on HOST1. So there are a lot of things that could be going wrong.

First thing I just wanted to see if I could receive UDP multi cast messages from any arbitrary program. I found these python scripts and ran them:

Send

import socket

MCAST_GRP = '224.1.1.1'
MCAST_PORT = 5007
# regarding socket.IP_MULTICAST_TTL
# ---------------------------------
# for all packets sent, after two hops on the network the packet will not 
# be re-sent/broadcast (see https://www.tldp.org/HOWTO/Multicast-HOWTO-6.html)
MULTICAST_TTL = 2

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, MULTICAST_TTL)
sock.sendto(b"robot", (MCAST_GRP, MCAST_PORT))

Recieve

import socket
import struct

MCAST_GRP = '224.1.1.1'
MCAST_PORT = 5007
IS_ALL_GROUPS = True

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
if IS_ALL_GROUPS:
    # on this port, receives ALL multicast groups
    sock.bind(('', MCAST_PORT))
else:
    # on this port, listen ONLY to MCAST_GRP
    sock.bind((MCAST_GRP, MCAST_PORT))
mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP), socket.INADDR_ANY)

sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

while True:
    print(sock.recv(10240))

I put it so HOST2 Receives and HOST1 Sends. At first this did not work. I digged into my router manual and unchecked this setting: Disable GMP Proxying - IGMP proxying allows a computer on the local area network (LAN) to receive the multicast traffic it is interested in from the Internet. If you do not need this feature, select this check box to disable it.

After I unchecked this then the python script for UDP Multicast send/receive worked between the two different hosts. Unfortunately ECAL is still not seeing the messages on HOST2.

Here is some output from some commands on HOST2 which may be useful (note it uses wireless interface wlp*):

(base) ➜  ~ ip route                                                   
default via 192.168.1.1 dev wlp59s0 proto dhcp metric 600
169.254.0.0/16 dev wlp59s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev wlp59s0 proto kernel scope link src 192.168.1.24 metric 600
239.0.0.0/8 dev wlp59s0 scope link

This next command is after launching ECAL Monitor on HOST2. I think this means that the application is joining the multicast group

(base) ➜  ~ netstat -gn
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.251
lo              1      224.0.0.1
wlp59s0         4      239.0.0.1
wlp59s0         1      224.0.0.251
wlp59s0         1      224.0.0.1
docker0         1      224.0.0.251
docker0         1      224.0.0.1
docker0         1      224.0.0.106
lo              1      ff02::fb
lo              1      ff02::1
lo              1      ff01::1
wlp59s0         1      ff02::fb
wlp59s0         1      ff02::1:ffdd:eca6
wlp59s0         1      ff02::1
wlp59s0         1      ff01::1
docker0         1      ff02::6a
docker0         1      ff02::1
docker0         1      ff01::1

This command is on HOST1 (publisher) after starting my ECAL publishing application. The enp6so (Ethernet interface) has new group under 239.0.*.

IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.251
lo              1      224.0.0.1
enp6s0          1      239.255.76.67
enp6s0          1      239.0.0.5
enp6s0          1      239.0.0.2
enp6s0          1      239.0.0.15
enp6s0          2      239.0.0.1
enp6s0          1      224.0.0.251
enp6s0          1      224.0.0.1
br-08146ed      1      224.0.0.251
br-08146ed      1      224.0.0.1
br-08146ed      1      224.0.0.106
docker0         1      224.0.0.251
docker0         1      224.0.0.1
docker0         1      224.0.0.106
lo              1      ff02::fb
lo              1      ff02::1
lo              1      ff01::1
enp6s0          1      ff02::fb
enp6s0          1      ff02::1:ffad:3a0d
enp6s0          1      ff02::1
enp6s0          1      ff01::1
wlp5s0          1      ff02::1
wlp5s0          1      ff01::1
br-08146ed772c2 1      ff02::6a
br-08146ed772c2 1      ff02::1
br-08146ed772c2 1      ff01::1
docker0         1      ff02::6a
docker0         1      ff02::1
docker0         1      ff01::1

I don't have any expectation for your company to resolve these issues. Just wondering if there was something obvious that I was missing or something sticking out that looked like the culprit.

The current Readme,md documentation is not fitting anymore to cover all aspects of installation, usage, development of eCAL. So we should reduce that one to a minimal introduction and move all the rest to the new location

https://continental.github.io/ecal/

Hi eCAL team,

trying to build your system on a Raspberry Pi 3B+ fails. Build stops first time when building the executable ecal_topic. The linker complains about undefined reference to
__atomic_load_8
__atomic_store_8
__atomic_fetch_add_8

It looks like a problem linking to -latomic which is necessary on armhf systems.

I'm using an actual raspbian (Buster) with GCC 8.3
During build there are a lot of warnings due to some changes after GCC 7.4.
Maybe the -latomic thing is a problem of using GCC 8 or cmake is doing something ugly.

Can you confirm my problem or is it an issue on my side/system?

Thanks!!

Describe the bug
When typing ecal_play into the console I receive following following error:
ecal_play: error while loading shared libraries: libhdf5.so.103: cannot open shared object file: No such file or directory

To Reproduce
Installed eCAL according to github page install instructions on Ubuntu 18.04. I am able to start eCAL-Monitor

Additional context
Output of apt list libhdf5-dev:
Listing... Done libhdf5-dev/bionic,now 1.10.0-patch1+docs-4 amd64 [installed]

Output of ls /usr/local/lib/libecal*:
/usr/local/lib/libecal_core_c.so
/usr/local/lib/libecal_core.so
/local/lib/libecal_EcalUtils.a
/local/lib/libecal_pb.a
/local/lib/libecaltime-localtime.so
/usr/local/lib/libecal_core_c.so.5
/local/lib/libecal_core.so.5
/local/lib/libecal_hdf5.a
/local/lib/libecal_proto.a
/local/lib/libecaltime-simtime.so
/usr/local/lib/libecal_core_c.so.5.5.0
/usr/local/lib/libecal_core.so.5.5.0
/usr/local/lib/libecal_mon_plugin_lib.a
/usr/local/lib/libecaltime-linuxptp.so

Hi, The LInux build instructions are missing mention of simpleini.
Could you add something there in the documentation? I can find a simpleini project in GitHub, but it is not the only one. Document what to put into the empty simpleini folder, for example.

Thanks

CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find simpleini (missing: simpleini_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/Findsimpleini.cmake:18 (find_package_handle_standard_args)
CMakeLists.txt:159 (_find_package)
ecal/core/src/CMakeLists.txt:24 (find_package)

Hello,

I'm currently creating an Arch Linux AUR package for eCal and there is only one minor nitpick left. I download the tagged release, patch it with the my compile-on-Arch-Linux patch, and then build from there. But as I'm not building from within a Git repository, the version detection in CMakeLists.txt fails and all my .so files end up with version 0.0.0.

This is not a showstopper as I can either patch or sed the CMakeLists.txt myself, but I think it would be nice in general if version detection would also work when building outside of a Git clone.

When installing an ecal python egg a compatible protobuf version for python needs to be installed additionally. Currently google is not supporting protobuf 3.11.4 for python, last supported version from the 3.11 line is 3.11.3.
We need to modify the required package dependency logic in the python egg generation to accept the best fitting protobuf version and not to request a specific one.

I have the following Error during the installation:
(Lese Datenbank ... 236012 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von eCAL-5.3.4-Linux.deb ... Entpacken von ecal (5.3.4) ... dpkg: Fehler beim Bearbeiten des Archivs eCAL-5.3.4-Linux.deb (--install): Versuch, »/usr/include/google/protobuf/descriptor.h« zu überschreiben, welches auch in Paket libprotobuf-dev:amd64 2.6.1-1.3 ist dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Broken pipe) getötet Fehler traten auf beim Bearbeiten von: eCAL-5.3.4-Linux.deb

How can I fix it?

I am trying to compile ecal for my Linux Ubuntu 18.04.2 but I am facing some dependencies issues.

First I had issues with Asio and tclap but both were fixed using:

sudo apt-get install libasio-dev

sudo apt-get install libtclap-dev

Now I am having issues with simpleini:

/usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 
(message):
   Could NOT find simpleini (missing: simpleini_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
   cmake/find_scripts/Findsimpleini.cmake:17 
(find_package_handle_standard_args)
   CMakeLists.txt:77 (_find_package)
   contrib/ecaltime/linuxptp/src/CMakeLists.txt:19 (find_package)


-- Configuring incomplete, errors occurred!

I tried installing liubinih-dev but I am still having the same issue.

What would be the best way to fix this dependency? I saw that there is a GitHub project at https://github.com/brofield/simpleini. Should I use this one? Can this dependencies be added to the README file?

Current cmake build toolchain supports VS2015 and VS2017. Since VS2019 is out for a while we should support that compiler too.

The new documentation is based on sphinx and needs to be build to reflect changes on the rst files on gihub-pages. This step should be automated by a github action rebuilding the documentation on a master pull request.

I am attempting to use ECAL inside of a separate C++ project with CMake. I have been able to successfully do this with ECAL 5.5.2. I am now trying to update and use 5.6.0. Inside my cloned ecal repo I have checked out the new release (tag) version and have updated all submodule dependencies. Here is may CMake configuration when building ecal for completeness:

cmake .. -DCMAKE_BUILD_TYPE=Release -DECAL_THIRDPARTY_BUILD_PROTOBUF=OFF -DHAS_QT5=OFF -DBUILD_DOCS=OFF -DECAL_THIRDPARTY_BUILD_CURL=OFF -DECAL_THIRDPARTY_BUILD_HDF5=OFF -DBUILD_PY_BINDING=ON
make -j20
cpack -G DEB
sudo dpkg -i _deploy/eCAL-*

There are no errors building or installing ecal. However when attempting to now use Ecal in another cmake project (toally different directory) I get this error. Note the error is about not finding tinyxml target. This is a new dependency that it seems is not being bundled or found correctly when using cpack.

CMake Error at /usr/lib/cmake/eCAL/eCALTargets-release.cmake:9 (set_property):
  set_property could not find TARGET tinyxml2::tinyxml2.  Perhaps it has not
  yet been created.
Call Stack (most recent call first):
  /usr/lib/cmake/eCAL/eCALTargets.cmake:131 (include)
  /usr/lib/cmake/eCAL/eCALConfig.cmake:60 (include)
  CMakeLists.txt:33 (find_package)


CMake Error at /usr/lib/cmake/eCAL/eCALTargets-release.cmake:10 (set_target_properties):
  set_target_properties Can not find target to add properties to:
  tinyxml2::tinyxml2
Call Stack (most recent call first):
  /usr/lib/cmake/eCAL/eCALTargets.cmake:131 (include)
  /usr/lib/cmake/eCAL/eCALConfig.cmake:60 (include)
  CMakeLists.txt:33 (find_package)

My guess is that something has gone wrong with "packaging" ecal using cpack. Specifically the tinyxml2 dependency. Here's an image of this directory if needed.

Everything works perfectly fine and build if I use Ecal 5.5.2

Thanks for any help!

Hello,

eCAL looks really simple to use comparing with ROS/ROS2. But maybe it is better to add more message types, especially the sensor message types?

For me I need to be able to send/get image type, point cloud type, and triangle-mesh data to/from topic and services using OpenCV and Open3D.

In ROS there are quite some sensor message types to choose.

Any suggestions?

Thank you!

In order to compile eCAL with qcc properly, some fixes and workarounds has to be applied to the source code and CMake configuration.

The Windows setup is genereated from a Release build. Thus, the setup only contains release binaries. When linking against the eCAL Setup in a debug build, you will end up with a mixed debug/release binary. As the C++ Debug ABI and C++ Release ABI are not compatible, the applications will crash when trying to pass STL containers to eCAL:

Linking against the C interface (eCAL::core_c) seems to work in a debug build. I however doubt that it is possible to produce a working debug binary with that workaround, once you use protobuf.

We therefore have to also ship the Debug built along in the Windows installer.

Also see #79

For a better documentation we should use github pages

The one and only Readme.md file is hard to maintain and not that comfortable to find the information you are looking for. Github pages should contain FAQ's, doxygen API documentation and also section related to build, setup and use eCAL.

Hey there,

in contrib/ecalhdf5/src/eh5_meas_dir.cpp, in the second ctor (line 52), you should set access_ (to RDONLY) so that the nested call to Close() does not read from uninitialized memory.

Currently, eCAL is not built with NPCAP support. I guess the Windows installer also does not support NPCAP (but not sure).
The documentation however teaches the user how to enable it, so we should also include it in the build.

Hi eCAL Team,

I have been using eCAL for a couple of days now transitioning over from a flavor of DDS. This project is great and apart from the great performance boost, I really like the monitoring tool.

I had a couple of requests/ questions:

1. As the title mentions I see that there is mention of this in the docs, so I was wondering is there a plan to have a Record and Replay utility ? It was something that was very handy when i was using DDS.

2. I was wondering if you could maybe either add to the docs or point me in the correct direction on how i would add a different serialization format to the monitoring tool ...like say capnproto ?

Thank You

Deploying python egg/extension in anaconda environment fails. Even following the instructions step by step, installing the extension within the system interpreter fails

Currently unit tests are not executed in case of using iceoryx shared memory layer. Lets switch them on and check :-)

I'm currently working on a simple bidirectional gateway between eCAL and WAMP using the Crossbar / Autobahn twisted library for Python.

Version:
eCAL v5.7.4 (03.11.2020)

The application terminates in roughly 50% with

terminate called without an active exception
Aborted (core dumped)

The error happens during initialization before any incoming eCAL messages. When the initialization succeeds the application continues running stable.

Source code: (without interface files, pls. ask for details)
ecal_bridge.py.tar.gz

The call stack retrieved with gdb is as follows:

(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007fde5fae8921 in __GI_abort () at abort.c:79
#2  0x00007fde5a3e6957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007fde5a3ecae6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fde5a3ecb21 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007fde5ac4821c in eCAL::CThread::Start(int, std::function<int ()>) () from /usr/lib/libecal_core.so.5
#6  0x00007fde5abf6443 in eCAL::CMulticastLayer::AddSubscription(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, eCAL::QOS::SReaderQOS) () from /usr/lib/libecal_core.so.5
#7  0x00007fde5abf266a in eCAL::CDataReader::StartDataLayers() () from /usr/lib/libecal_core.so.5
#8  0x00007fde5abf4615 in eCAL::CDataReader::Create(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libecal_core.so.5
#9  0x00007fde5abeac1a in eCAL::CSubscriber::Create(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libecal_core.so.5
#10 0x00007fde5ac2a33f in sub_create(char const*, char const*) () from /usr/lib/libecal_core.so.5
#11 0x00007fde5b55d41c in sub_create(_object*, _object*) () from /usr/local/lib/python3.6/dist-packages/ecal-5.7.3-bionic-py3.6.egg/ecal/_ecal_core_py.so
#12 0x000000000050a12f in ?? ()
#13 0x000000000050beb4 in _PyEval_EvalFrameDefault ()
#14 0x00000000005095c8 in ?? ()
#15 0x000000000050a2fd in ?? ()
#16 0x000000000050beb4 in _PyEval_EvalFrameDefault ()
#17 0x0000000000507be4 in ?? ()
... (more Python stack frames)

Iceoryx realized a zero copy shared memory data transfer following the publish / subscribe pattern. The layered eCAL architecture allows to utilize / combine different transport protocols without interfering the high level API mechanisms.

Even Iceoryx is only available for POSIX systems it would be interesting to check the performance against the existing eCAL shared memory transport layer.

https://readthedocs.org/ seems to be an interesting way to document eCAL API in different formats and based on the repo sources. Let's evaluate this option ..

Howdy!

https://github.com/continental/ecal/blob/master/ecal/core/include/ecal/cimpl/ecal_subscriber_cimpl.h#L109

I believe that this should declare the buf_ parameter as void** and not void*. There isn't a problem calling this and passing a reference to a void* in C or C++; but when generating the FFI interface for other languages it's going to cause troubles.
In my case, the code generated by bindgen prevented me from using this function.

I'm happy to submit a PR.

Cheers,
Chip

if I collect a long measurement which gets splitted into several the player shows the following error if I open a single hdf5 file the channel mapping can't be saved.

Hi, is there a way to run eCAL on the NVidia Jetson TX2 Embedded device?

Hi!

I've just downloaded in a Ubuntu 20.04 your source code (version 5.7.2), installed the dependencies, and tried to compile eCAL from the source code. I'm getting an error when the cmake command is executed.

sudo cmake .. -DCMAKE_BUILD_TYPE=Release -DECAL_THIRDPARTY_BUILD_PROTOBUF=OFF -DECAL_THIRDPARTY_BUILD_CURL=OFF -DECAL_THIRDPARTY_BUILD_HDF5=OFF
-- Module Path: /home/jmagundezg/tfg/ecal/ecal-5.7.2/cmake;/home/jmagundezg/tfg/ecal/ecal-5.7.2/cmake/Modules
-- Prefix Path: 
CMake Error at CMakeLists.txt:147 (add_subdirectory):
  The source directory

    /home/jmagundezg/tfg/ecal/ecal-5.7.2/thirdparty/spdlog

  does not contain a CMakeLists.txt file.


CMake Error at CMakeLists.txt:149 (add_library):
  add_library cannot create ALIAS target "spdlog::spdlog" because target
  "spdlog" does not already exist.


CMake Error at CMakeLists.txt:159 (add_subdirectory):
  The source directory

    /home/jmagundezg/tfg/ecal/ecal-5.7.2/thirdparty/tinyxml2

  does not contain a CMakeLists.txt file.


CMake Error at CMakeLists.txt:160 (add_library):
  add_library cannot create ALIAS target "tinyxml2::tinyxml2" because target
  "tinyxml2" does not already exist.


CMake Error at CMakeLists.txt:165 (add_subdirectory):
  add_subdirectory given source "thirdparty/fineftp-server/fineftp-server"
  which is not an existing directory.


CMake Error at CMakeLists.txt:166 (set_property):
  set_property could not find TARGET server.  Perhaps it has not yet been
  created.


CMake Error at CMakeLists.txt:167 (add_library):
  add_library cannot create ALIAS target "fineftp::server" because target
  "server" does not already exist.


-- Content of the message: fatal: no es un repositorio git (ni ninguno de los directorios superiores): .git

-- This is not a git repository, assuming source tree build
-- GCC detected - Adding flags
-- Could NOT find Asio (missing: Asio_INCLUDE_DIR) 
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
  Could NOT find tclap (missing: tclap_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
  cmake/Modules/Findtclap.cmake:18 (find_package_handle_standard_args)
  CMakeLists.txt:276 (_find_package)
  ecal/core/CMakeLists.txt:23 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/jmagundezg/tfg/ecal/ecal-5.7.2/_build/CMakeFiles/CMakeOutput.log".
See also "/home/jmagundezg/tfg/ecal/ecal-5.7.2/_build/CMakeFiles/CMakeError.log".

Am I doing something wrong?

Cheers.

According to the documentation this Dockerfile should work.

The installation breaks at the cmake command.

FROM debian:latest

RUN apt-get update && apt-get install -y \
	git \
	cmake \
	doxygen \
	graphviz \
	build-essential \
	zlib1g-dev \
	qt5-default

RUN git clone --recursive --depth 1 git://github.com/continental/ecal.git

RUN cd /ecal && \
	mkdir _build && \
	cd _build && \
	cmake .. -DCMAKE_BUILD_TYPE=Release && \
	make -j && \
	cpack -G DEB && \
	sudo dpkg -i eCAL*

CMD ["sleep", "infinity"]

Feature request:

It would be great if you could create a Dockerfile like this with a working installation.

At the moment, the eCAL Mon Plugin dir is hardcoded. Thus, no plugin is found when building eCAL with multiarch install dirs (i.e. -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu).

Point for discussion

I believe providing mechanisms to build very common/widespread third party libraries like protobuf and asio in-tree as part of the ecal build process is not best practice.

It might be a welcome crutch for quick installation on a developer's local system. But for proper deployment on a target, the dependencies should be explicitly handled. There is a high chance that the user will also need other (non ecal) components that depend on these libraries. Other (incompatible) versions of these libraries might already pre-exist on the target systems. With the possibility to build in-tree (ECAL_THIRDPARTY_BUILD...), developers will be lead into using this, and might end up with duplicate libraries on a resource restricted embedded target. Better to clearly specify the dependencies, and have the developers or integrators do their work.

I am a little on the fence on less prevalent and/or possibly outdated third party dependencies (for example simpleini). For these cases, it might be more reasonable to provide them in-tree (in some cases maybe even going as far as having a copy in-tree, not as git sub-modules). But in general, I think best practice is to make third party dependencies explicit, document them well, and have the developer handle them.

This has the added side-effect of keeping the CMakeLists.txt structure a bit simpler. The ecal one is complicated enough as it is ;)

Describe the bug
I was wondering if ECAL can handle having a publisher on one thread and a subscriber on another thread. I am using std:thread to spawn a separate publishing thread while the main thread just subscribes to those messages.

The below example does not work. The publishing thread is spawned and messages are continously sent. However the OnReceive callback is never fired which is connected to the main thread.

I know that messages are being published correctly because I can create another indepent program that only subscribes to these messages and they are received. So the issue seems to be on the main thread (receiving).

To Reproduce

void publish()
{
	eCAL::CPublisher pub("Counter", "long long");
	// idle main thread
	while(eCAL::Ok())
	{
		// sleep 100 ms
		std::cout << "Sending data on seperate thread" << std::endl;
		long long start_time_loop = eCAL::Time::GetMicroSeconds();
		pub.Send(&start_time_loop, sizeof(long long));
		eCAL::Process::SleepMS(1000);
	}

}
void OnReceive(const char* /* topic_name_ */, const struct eCAL::SReceiveCallbackData* data_)
{
	std::string rec_buf;
	std::cout << "Received data on main thread: " << std::endl;
}

int main(int argc, char* argv[])
{
	  // initialize eCAL API
	eCAL::Initialize(0, nullptr, "RSTrackerSub");
        eCAL::CSubscriber sub("Counter", "long long");

  	// setup receive callback function
  	sub.AddReceiveCallback(OnReceive);

	auto t1 = std::thread(publish);
  	// idle main thread
	while(eCAL::Ok())
	{
		// sleep 100 ms
		std::cout << "Main thread loop waiting for messages" << std::endl;
		eCAL::Process::SleepMS(1000);
	}

}

Output:

root@33c34a5aa5d0:/opt/workspace/build# ../bin/rs-test 
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread
Main thread loop waiting for messages
Sending data on seperate thread

To simplify ci/cd we should move from Appveyor / Travis to GitHub Actions (supporting Windows / Linux and MacOS).

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

How to check the version of the installed ecal in Linux? Thanks!

Hello,

I use a VM to install, and follow the instructions to build the software but fails by the step
Compile eCAL
4.Create and install the eCAL python egg
cmake --build . --target create_python_egg --config Release

when I run cmake --build . --target create_python_egg --config Release， it shows "No rule to make target"create_python_egg", Stop ".

What is the reason?

Info:
Ubuntu 18.04.

Thanks

Hello,

while dockerizing eCAL for my home use, I noticed that DEB package actually puts ecal.ini and ecaltime.ini under /usr/etc/ (and make install puts it under /usr/local/etc). I do not care so much about /usr/local, but maybe it's a nice idea for known so Linux-savy users to add the "-DCMAKE_INSTALL_SYSCONFDIR=/etc" to the cmake command in the documentation or at least add a comment about that so that the resulting DEB package from cpack will put the configuration files to a more intuitive location.

I will also add that flag to the AUR Arch Linux package instead of moving the config files around before packaging like I currently do.

Thank you for your work!

The current conanfile.txt in this repo is using packages that are not automatically or easily resolved.

It would be helpful to know where kwc_bintray is and add this to the README so that others can use Conan.

Digging around the commit and issue history I see that this was contributed by someone from Kai Wolf (so kwc seems to make sense). So it appears as though they have a self-hosted artifactory service but not all the packages were listed. At which point I realized that it's probably https://bintray.com/kwc which is rather easy in hindsight.

Running conan remote add kwc_bintray https://api.bintray.com/conan/kwc/conan resolved this for me.

Then you apparently also need bincrafters:
conan remote add bincrafters https://api.bintray.com/conan/bincrafters/public-conan

But you finally end up with the issue of the version of protobuf being requested is not apparently available in the bincrafters public conan repository. However, the requested version is available on conan-center. But still missing is protoc_installer.

It would be useful to add some documentation for the level of Conan support in the repo and how to use it.

To improve overall software quality it would be nice to introduce a static code analysis tool. Let's start with one of my favorites PVS Studio :-)