I want the Ouster to have a destaggered (organized) Point Cloud published. As per the documentation located at https://static.ouster.dev/sdk-docs/reference/lidar-scan.html#staggering-and-destaggering, there is a function available for destaggering.
I know that the destagger function must be used in os_ros.cpp before line 230.

But it still doesn't work. I destaggered the range before line 230 in ouster-ros/src/os_ros.cpp.

Eigen::Ref<const ouster::img_t<uint32_t>> refrange = range;
range = ouster::destagger(refrange,pixel_shift_by_row);

But the published point cloud is still staggered. Is it because a staggered range is a timestep X scanline matrix and a destaggered range is an azimuth angle X scanline matrix. However, in the function destagger(const Eigen::Ref<const img_t>& img, const std::vector& pixel_shift_by_row, bool inverse) the size of the return matrix is ​​set to the size of img.
As I understand it the return matrix is a matrix with the size timestep X scanline and not a destaggerd matrix with the size of azimuth angle X scanline matrix .
Or is the Ouster azimuth angle number equal to the number of timesteps per scan?
And what is the reason that only the range must be destaggerd and not also the reflectivity?

Hi,

I am trying to run the driver with a OS1-16 (FW 2.4) lidar (Part number 840-101855-02):
roslaunch ouster_ros sensor.launch sensor_hostname:=os1-99XXXX.local

Unfortunately the driver crashes:
/opt/ros/noetic/lib/nodelet/nodelet: line 1: 44277 Segmentation fault (core dumped) $0 $@

I tried with another OS1-16 (FW 2.0), same problem.
When I use the OusterStudio, I can see the data and everything seems to work well.

If I remove the cloud nodelet from common.launch (removing line 9 to 17), I can see the topics /ouster/lidar_packets and /ouster/imu_packets at 640Hz and 100Hz, respectively.

Putting back the nodelet in the launch file, and inserting prints in the code, it seems that the error is coming from the call to scan_to_cloud in os_cloud_nodelet.cpp (see below for the code modifications and the whole print)

Do you know what could cause this and how to solve it ?

Thanks
Cedric

Code modification for prints

os_cloud_nodelet.cpp from line 107

void convert_scan_to_pointcloud_publish(std::chrono::nanoseconds scan_ts, const ros::Time& msg_ts) {
      for (int i = 0; i < n_returns; ++i) {
          NODELET_INFO("BEFORE SCAN TO CLOUD");
          scan_to_cloud(xyz_lut, scan_ts, ls, cloud, i); 
          NODELET_INFO("AFTER SCAN TO CLOUD");
          sensor_msgs::PointCloud2 pc =
              ouster_ros::cloud_to_cloud_msg(cloud, msg_ts, sensor_frame);

os_ros.cpp from line 127

  void scan_to_cloud(const ouster::XYZLut& xyz_lut,
                     ouster::LidarScan::ts_t scan_ts, const ouster::LidarScan& ls,
                     ouster_ros::Cloud& cloud, int return_index) {
      std::cout << "START SCAN TO CLOUD" << std::endl;
      bool second = (return_index == 1);
      cloud.resize(ls.w * ls.h);
  
      ouster::img_t<uint16_t> near_ir = get_or_fill_zero<uint16_t>(
          suitable_return(sensor::ChanField::NEAR_IR, second), ls);
  
      ouster::img_t<uint32_t> range = get_or_fill_zero<uint32_t>(
          suitable_return(sensor::ChanField::RANGE, second), ls);
  
      ouster::img_t<uint32_t> signal = get_or_fill_zero<uint32_t>(
          suitable_return(sensor::ChanField::SIGNAL, second), ls);
  
      ouster::img_t<uint16_t> reflectivity = get_or_fill_zero<uint16_t>(
          suitable_return(sensor::ChanField::REFLECTIVITY, second), ls);
  
      auto points = ouster::cartesian(range, xyz_lut);
      auto timestamp = ls.timestamp();
  
      for (auto u = 0; u < ls.h; u++) {
          for (auto v = 0; v < ls.w; v++) {
              const auto xyz = points.row(u * ls.w + v);
              const auto ts =
                  (std::chrono::nanoseconds(timestamp[v]) - scan_ts).count();
              cloud(v, u) = ouster_ros::Point{
                  {{static_cast<float>(xyz(0)), static_cast<float>(xyz(1)),
                    static_cast<float>(xyz(2)), 1.0f}},
                  static_cast<float>(signal(u, v)),
                  static_cast<uint32_t>(ts),
                  static_cast<uint16_t>(reflectivity(u, v)),
                  static_cast<uint8_t>(u),
                  static_cast<uint16_t>(near_ir(u, v)),
                  static_cast<uint32_t>(range(u, v))};
          }
      }
      std::cout << "END SCAN TO CLOUD" << std::endl;
  }

Print

ced@ced-notebook:~/catkin_ws$ roslaunch ouster_ros sensor.launch sensor_hostname:=os1-991924000182.local
... logging to /home/ced/.ros/log/da7c9372-7b47-11ed-81e5-af45f6f59e16/roslaunch-ced-notebook-46887.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://ced-notebook:36061/

SUMMARY
========

PARAMETERS
 * /ouster/os_cloud_node/tf_prefix: 
 * /ouster/os_cloud_node/timestamp_mode: 
 * /ouster/os_node/imu_port: 0
 * /ouster/os_node/lidar_mode: 
 * /ouster/os_node/lidar_port: 0
 * /ouster/os_node/metadata: 
 * /ouster/os_node/sensor_hostname: os1-991924000182....
 * /ouster/os_node/timestamp_mode: 
 * /ouster/os_node/udp_dest: 
 * /ouster/os_node/udp_profile_lidar: 
 * /rosdistro: noetic
 * /rosversion: 1.15.15

NODES
  /
    relay_imu (topic_tools/relay)
    relay_lidar (topic_tools/relay)
    rviz (rviz/rviz)
  /ouster/
    img_node (nodelet/nodelet)
    os_cloud_node (nodelet/nodelet)
    os_node (nodelet/nodelet)
    os_nodelet_mgr (nodelet/nodelet)

ROS_MASTER_URI=http://localhost:11311

process[ouster/os_nodelet_mgr-1]: started with pid [46901]
process[ouster/os_node-2]: started with pid [46903]
process[ouster/os_cloud_node-3]: started with pid [46905]
process[ouster/img_node-4]: started with pid [46907]
process[rviz-5]: started with pid [46909]
process[relay_lidar-6]: started with pid [46911]
process[relay_imu-7]: started with pid [46912]
[ INFO] [1671004161.300918715]: Initializing nodelet with 16 worker threads.
[ INFO] [1671004162.292009813]: Loading nodelet /ouster/os_node of type nodelets_os/OusterSensor to manager os_nodelet_mgr with the following remappings:
[ WARN] [1671004162.322284296]: lidar port set to zero, the client will assign a random port number!
[ WARN] [1671004162.322318282]: imu port set to zero, the client will assign a random port number!
[ INFO] [1671004162.322330235]: Will use automatic UDP destination
[ WARN] [1671004162.523428897]: Sensor os1-991924000182.local configured successfully
[ INFO] [1671004162.523496398]: Starting sensor os1-991924000182.local initialization...
[2022-12-14 18:49:22.523] [ouster::sensor] [info] initializing sensor: os1-991924000182.local with ports: 0/0
[ INFO] [1671004163.304245202]: Loading nodelet /ouster/os_cloud_node of type nodelets_os/OusterCloud to manager os_nodelet_mgr with the following remappings:
[ INFO] [1671004163.315182665]: Loading nodelet /ouster/img_node of type nodelets_os/OusterImage to manager os_nodelet_mgr with the following remappings:
[ INFO] [1671004164.462140984]: rviz version 1.14.19
[ INFO] [1671004164.462257601]: compiled against Qt version 5.12.8
[ INFO] [1671004164.462290375]: compiled against OGRE version 1.9.0 (Ghadamon)
[ INFO] [1671004164.487389621]: Forcing OpenGl version 0.
[ INFO] [1671004164.834589265]: Stereo is NOT SUPPORTED
[ INFO] [1671004164.834710320]: OpenGL device: AMD RENOIR (DRM 3.42.0, 5.15.0-56-generic, LLVM 12.0.0)
[ INFO] [1671004164.834747552]: OpenGl version: 4.6 (GLSL 4.6) limited to GLSL 1.4 on Mesa system.
[ WARN] [1671004174.663111320]: Client version: 0.7.1b1+279c9fb-release
[ WARN] [1671004174.663188780]: Using lidar_mode: 1024x10
[ WARN] [1671004174.663212827]: OS-1-16-B13 sn: 991924000182 firmware rev: v2.4.0
[ WARN] [1671004174.664660523]: No metadata file was specified, using: os1-991924000182-metadata.json
[ INFO] [1671004174.671251261]: Wrote metadata to os1-991924000182-metadata.json
[ INFO] [1671004174.672399154]: get_metadata service created
[ INFO] [1671004174.673270749]: get_config service created
[ INFO] [1671004174.674070484]: set_config service created
[ INFO] [1671004174.686210956]: OusterCloud: retrieved sensor metadata!
[ INFO] [1671004174.686743341]: Profile has 1 return(s)
[ INFO] [1671004174.703401891]: OusterImage: retrieved sensor metadata!
[ INFO] [1671004174.779948376]: BEFORE SCAN TO CLOUD
START SCAN TO CLOUD
END SCAN TO CLOUD
/opt/ros/noetic/lib/nodelet/nodelet: line 1: 46927 Segmentation fault      (core dumped) $0 $@
================================================================================REQUIRED process [ouster/os_nodelet_mgr-1] has died!
process has died [pid 46901, exit code 139, cmd bash -c sleep 2; $0 $@ /opt/ros/noetic/lib/nodelet/nodelet manager __name:=os_nodelet_mgr __log:=/home/ced/.ros/log/da7c9372-7b47-11ed-81e5-af45f6f59e16/ouster-os_nodelet_mgr-1.log].
log file: /home/ced/.ros/log/da7c9372-7b47-11ed-81e5-af45f6f59e16/ouster-os_nodelet_mgr-1*.log
Initiating shutdown!
================================================================================
[relay_imu-7] killing on exit
[relay_lidar-6] killing on exit
[rviz-5] killing on exit
[ouster/img_node-4] killing on exit
[ouster/os_cloud_node-3] killing on exit
[ouster/os_node-2] killing on exit
[ouster/os_nodelet_mgr-1] killing on exit
[ INFO] [1671004176.145572739]: Unloading nodelet /ouster/img_node from manager os_nodelet_mgr
[ INFO] [1671004176.145744433]: Unloading nodelet /ouster/os_cloud_node from manager os_nodelet_mgr
[ INFO] [1671004176.145951796]: Unloading nodelet /ouster/os_node from manager os_nodelet_mgr
[ INFO] [1671004176.146997671]: waitForService: Service [/ouster/os_nodelet_mgr/unload_nodelet] could not connect to host [ced-notebook:43405], waiting...
[ WARN] [1671004176.147052026]: Couldn't find service os_nodelet_mgr/unload_nodelet, perhaps the manager is already shut down
[ INFO] [1671004176.147513684]: waitForService: Service [/ouster/os_nodelet_mgr/unload_nodelet] could not connect to host [ced-notebook:43405], waiting...
[ WARN] [1671004176.147569322]: Couldn't find service os_nodelet_mgr/unload_nodelet, perhaps the manager is already shut down
[ INFO] [1671004176.147890167]: waitForService: Service [/ouster/os_nodelet_mgr/unload_nodelet] could not connect to host [ced-notebook:43405], waiting...
[ WARN] [1671004176.147934222]: Couldn't find service os_nodelet_mgr/unload_nodelet, perhaps the manager is already shut down
shutting down processing monitor...
... shutting down processing monitor complete
done

Hi everyone,

I'm trying to connect sensor os0-32 on ubuntu 18.04 with ros Melodic. I'm using the FW 2.4, when I initialize for command: roslaunch ouster_ros sensor.launch sensor_hostname:=os-122137000149.local, I get this image on RVIZ.

I'm trying to connect to an Ouster OS1-128 (firmware v2.4.0) with the ouster_ros node.
With the Ouster Studio I can connect correctly to the sensor and visualize the point clouds correctly.

The Ouster-OS1-128 is configured with an fixed IP.

When I rune the following command on the same machine, the communication fails.
Any idea?

Ouster-Ros Node
roslaunch ouster_ros sensor.launch sensor_hostname:=192.0.2.100 udp_dest:=192.0.2.10 lidar_port:=7502 imu_port:=7503 viz:=false

Log

SUMMARY
========

PARAMETERS
 * /ouster/os_cloud_node/tf_prefix: 
 * /ouster/os_cloud_node/timestamp_mode: 
 * /ouster/os_node/imu_port: 7503
 * /ouster/os_node/lidar_mode: 
 * /ouster/os_node/lidar_port: 7502
 * /ouster/os_node/metadata: 
 * /ouster/os_node/sensor_hostname: 192.0.2.100
 * /ouster/os_node/timestamp_mode: 
 * /ouster/os_node/udp_dest: 192.0.2.10
 * /ouster/os_node/udp_profile_lidar: 
 * /rosdistro: noetic
 * /rosversion: 1.15.15

NODES
  /
    relay_imu (topic_tools/relay)
    relay_lidar (topic_tools/relay)
  /ouster/
    img_node (nodelet/nodelet)
    os_cloud_node (nodelet/nodelet)
    os_node (nodelet/nodelet)
    os_nodelet_mgr (nodelet/nodelet)

ROS_MASTER_URI=http://localhost:11311

process[ouster/os_nodelet_mgr-1]: started with pid [5789]
process[ouster/os_node-2]: started with pid [5791]
process[ouster/os_cloud_node-3]: started with pid [5793]
process[ouster/img_node-4]: started with pid [5795]
process[relay_lidar-5]: started with pid [5797]
process[relay_imu-6]: started with pid [5798]
[ INFO] [1674827893.786712145]: Initializing nodelet with 8 worker threads.
[ INFO] [1674827894.766520780]: Loading nodelet /ouster/os_node of type nodelets_os/OusterSensor to manager os_nodelet_mgr with the following remappings:
[ INFO] [1674827894.797790246]: Will send UDP data to 192.0.2.10
[ERROR] [1674827894.799617669]: Error setting config:  CurlClient::execute_get failed for the url: [http://192.0.2.100/api/v1/system/firmware] with the error message: Couldn't connect to server
[FATAL] [1674827894.799853300]: Failed to load nodelet '/ouster/os_node` of type `nodelets_os/OusterSensor` to manager `os_nodelet_mgr'
================================================================================REQUIRED process [ouster/os_node-2] has died!
process has died [pid 5791, exit code 255, cmd bash -c sleep 3; $0 $@ /opt/ros/noetic/lib/nodelet/nodelet load nodelets_os/OusterSensor os_nodelet_mgr __name:=os_node __log:=/home/ae/.ros/log/3344174c-9e42-11ed-84fd-553d1d5567c9/ouster-os_node-2.log].
log file: /home/ae/.ros/log/3344174c-9e42-11ed-84fd-553d1d5567c9/ouster-os_node-2*.log
Initiating shutdown!
================================================================================
[relay_imu-6] killing on exit
[relay_lidar-5] killing on exit
[ouster/img_node-4] killing on exit
[ouster/os_cloud_node-3] killing on exit
[ouster/os_node-2] killing on exit
[ouster/os_nodelet_mgr-1] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Hi, I wonder if it really good practice to have separate msg and srv pkgs in project. As I see, the messages and services are only used within ouster-driver. That makes me think, that msg and srv can be defined in the ouster-driver pkg. That way we can reduce count of pkgs from three to two (lets not taking into account sdk submodule). If current structure of projects was not made for purpose, I can help to combine msg and srv into ouster-ros pkg

Hello,

We are currently syncing our sensor with the default-relaxed profile.
We would like to switch to the automotive-slave profile, but we can't get it to sync properly.
/api/v1/time/ptp shows the profile is correctly set to automotive-slave , but gm_present is false.

Our ptp master client is ptp4l version 3.1.1 and we added the following config to the default ptp config file (inspired from https://github.com/richardcochran/linuxptp/blob/v3.1.1/configs/automotive-master.cfg)

BMCA			noop
masterOnly		1
inhibit_announce	1
asCapable               true
inhibit_delay_req       1

Does anyone have a working ptp4l config file with the automotive profile? Thanks!

Is there any way to read ouster .pcap files from the ros node ?

I tried to build the ouster ros docker container using the following command.

docker build -t ouster_test .

There were two error messages, ultimately leading to it to fail to build.

`CMake Error at ouster-ros/CMakeLists.txt:4 (include):
include could not find load file:

DefaultBuildType`

CMake Error at /opt/ros/melodic/share/catkin/cmake/catkin_package.cmake:305 (message): catkin_package() include dir 'ouster-sdk/ouster_client/include' does not exist relative to '/var/lib/build/src/ouster-ros' Call Stack (most recent call first): /opt/ros/melodic/share/catkin/cmake/catkin_package.cmake:102 (_catkin_package) ouster-ros/CMakeLists.txt:42 (catkin_package)

How can this be fixed?

Here was the full output.

`Sending build context to Docker daemon 351.7kB
Step 1/18 : ARG ROS_DISTRO=melodic
Step 2/18 : FROM ros:${ROS_DISTRO}-ros-core AS build-env
---> 367edf3bdb41
Step 3/18 : ENV DEBIAN_FRONTEND=noninteractive BUILD_HOME=/var/lib/build OUSTER_ROS_PATH=/opt/catkin_ws/src/ouster-ros
---> Using cache
---> a064e66a0432
Step 4/18 : RUN set -xue && [ $ROS_DISTRO = "noetic" ] && PY=python3 || PY=python && echo 'APT::Install-Recommends "0";' > /etc/apt/apt.conf.d/01norecommend && apt-get update && apt-get install -y build-essential cmake fakeroot dpkg-dev debhelper $PY-rosdep $PY-rospkg $PY-bloom
---> Using cache
---> 93917e1ba8ae
Step 5/18 : RUN apt-get install -y curl libcurl4-openssl-dev
---> Using cache
---> 7388d042f63f
Step 6/18 : ARG BUILD_UID=1000
---> Using cache
---> 66b3c9eed365
Step 7/18 : ARG BUILD_GID=${BUILD_UID}
---> Using cache
---> 8ae466e24401
Step 8/18 : RUN set -xe && groupadd -o -g ${BUILD_GID} build && useradd -o -u ${BUILD_UID} -d ${BUILD_HOME} -rm -s /bin/bash -g build build
---> Using cache
---> ca256220f449
Step 9/18 : COPY --chown=build:build package.xml $OUSTER_ROS_PATH/package.xml
---> Using cache
---> f9dc3963396e
Step 10/18 : RUN set -xe && apt-get update && rosdep init && rosdep update --rosdistro=$ROS_DISTRO && rosdep install -y --from-paths $OUSTER_ROS_PATH
---> Using cache
---> 92ca52eef11f
Step 11/18 : COPY --chown=build:build . $OUSTER_ROS_PATH
---> Using cache
---> b6bba3f906fd
Step 12/18 : USER build:build
---> Using cache
---> e77161345da7
Step 13/18 : WORKDIR ${BUILD_HOME}
---> Using cache
---> 61b9b8928e86
Step 14/18 : RUN set -xe && mkdir src && cp -R $OUSTER_ROS_PATH ./src
---> Using cache
---> 4270a35a5bd4
Step 15/18 : FROM build-env
---> 4270a35a5bd4
Step 16/18 : ENV CXXFLAGS="-Werror -Wno-deprecated-declarations"
---> Using cache
---> afef28b2e069
Step 17/18 : RUN /opt/ros/$ROS_DISTRO/env.sh catkin_make -DCMAKE_BUILD_TYPE=Release && /opt/ros/$ROS_DISTRO/env.sh catkin_make install
---> Running in 92f3ef7b90a7
-- The C compiler identification is GNU 7.5.0
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /var/lib/build/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/melodic
-- This workspace overlays: /opt/ros/melodic
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.17", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python2
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /var/lib/build/build/test_results
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python2 (found version "2.7.17")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.29
-- BUILD_SHARED_LIBS is on
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~ traversing 1 packages in topological order:
-- ~~ - ouster_ros
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'ouster_ros'
-- ==> add_subdirectory(ouster-ros)
CMake Error at ouster-ros/CMakeLists.txt:4 (include):
include could not find load file:

DefaultBuildType

-- Checking for module 'eigen3'
-- Found eigen3, version 3.3.4
-- Found eigen: /usr/include/eigen3
-- Boost version: 1.65.1
-- Found the following Boost libraries:
-- system
-- filesystem
-- thread
-- date_time
-- iostreams
-- serialization
-- chrono
-- atomic
-- regex
-- looking for PCL_COMMON
-- Found PCL_COMMON: /usr/lib/x86_64-linux-gnu/libpcl_common.so
-- Found PCL: /usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_iostreams.so;/usr/lib/x86_64-linux-gnu/libboost_serialization.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libpthread.so;optimized;/usr/lib/x86_64-linux-gnu/libpcl_common.so;debug;/usr/lib/x86_64-linux-gnu/libpcl_common.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_iostreams.so;/usr/lib/x86_64-linux-gnu/libboost_serialization.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libpthread.so
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.58.0")
-- Boost version: 1.65.1
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- ouster_ros: 1 messages, 3 services
CMake Error at /opt/ros/melodic/share/catkin/cmake/catkin_package.cmake:305 (message):
catkin_package() include dir 'ouster-sdk/ouster_client/include' does not
exist relative to '/var/lib/build/src/ouster-ros'
Call Stack (most recent call first):
/opt/ros/melodic/share/catkin/cmake/catkin_package.cmake:102 (_catkin_package)
ouster-ros/CMakeLists.txt:42 (catkin_package)

-- Configuring incomplete, errors occurred!
See also "/var/lib/build/build/CMakeFiles/CMakeOutput.log".
See also "/var/lib/build/build/CMakeFiles/CMakeError.log".
Base path: /var/lib/build
Source space: /var/lib/build/src
Build space: /var/lib/build/build
Devel space: /var/lib/build/devel
Install space: /var/lib/build/install
Creating symlink "/var/lib/build/src/CMakeLists.txt" pointing to "/opt/ros/melodic/share/catkin/cmake/toplevel.cmake"

Running command: "cmake /var/lib/build/src -DCMAKE_BUILD_TYPE=Release -DCATKIN_DEVEL_PREFIX=/var/lib/build/devel -DCMAKE_INSTALL_PREFIX=/var/lib/build/install -G Unix Makefiles" in "/var/lib/build/build"

Invoking "cmake" failed
The command '/bin/sh -c /opt/ros/$ROS_DISTRO/env.sh catkin_make -DCMAKE_BUILD_TYPE=Release && /opt/ros/$ROS_DISTRO/env.sh catkin_make install' returned a non-zero code: 1`

Hello,

I'm trying to record data provided by a lidar OS1-64 and by a basler insdustrial camera on a Jetson Xavier board. For that, I use the two ros packages ouster_ros and pylon_camera. These two sensors are connected via Ethernet and each camera uses a specific IP address (the thoughput on the GiE is not saturated ~ 50%).

When I use OS1-64 alone, I get :

• /os_node/lidar_packet 76650 msgs by minute
• /os_node/lidar_imu 5988 msgs by minute

But when I use the two sensors together, all is ok for the camera but the messages falling down to 366 for the /os_node/lidar_packet... There are clairly a conflict between this two packages and ethernet configuration but I don't understand why ? Especially since with another lidar and package (hesai), I don't have this problem.

I seen similary issue in the history github "Messages get dropped [ros melodic + industrial camera] ouster-lidar/ouster_example#225" but there is no solution.

Thanks for your help.

How can we combine the changes that we've made in ROS2 to enable different time sources into the ouster_client so that we can make migration between firmware version easier

Hi everyone,

I would like to revisit this issue ouster-lidar/ouster_example#205 from two years ago to get some information on you plans about ROS2.
More and more applications and drivers are shifting to ROS2 which makes it increasingly frustrating to work with ROS1 packages.

I am aware that there is a ROS2 driver by the community (https://github.com/ros-drivers/ros2_ouster_drivers), but it still lacks some key features such as the Dual Return mode.

From Ouster distribution we got the information, that a official ROS2 driver is in the works and could potentially be released in the first half of 2023. Here on github it more seems like you try to cooperate with the community driver.

Could elaborate a bit on what to expect from the upcoming months as a user. It is very time consuming to implement things like ROS bridge or switching Distros, so this could help us a lot with planing on where to put resources.

Thanks in advance!

I have an OS1-Rev7 sensor. We plan to use time sync via NMEA messaging the ouster guide mentions that we can check the sync status on the sensor via TCP command "get_time_info". https://static.ouster.dev/sensor-docs/gps_guide/gps_guide.html
I was wondering how it can be achieved through ros interface. Is there any ROS service which can give this info?

Hi everyone:

I am sorry that I am fresh and I would like to ask that how can I change the format of ouster into Velodyne like format. I found the code here:

void ouster_driver::OS1::convert2XYZIR | ( | const CloudOS1 & | in,
  |   | CloudOS1XYZIR & | out
  | )

but I did not know which code and which part of the code should I change, thx!

As i mentioned in this comment we use some other features for our work with ouster ros driver.
The main feature is os_cloud_merger_nodelet. This nodelet can merge clouds from several os_cloud_nodelets with standart ROS ApproximatePolicy Synchronizer. Also we can transform this cloud to preferred frame and use box filter on it. We use it on our robot with 2 ouster sensors on it, may be other users with multi-lidars setup need something like this

I can make a PR if you interested in this functionality.

I would like to pass an Ouster LiDAR Sample Data file in pcap file format to the driver and receive a bag file or a pcl file. How can I do that?

Hello,

I have an ouster (OS0) in a fixed position, I would like to rotate the orientation, so the X-axis is pointing 90 degrees to the left (like below)

I am a bit confused by the manual on how to do so.

Do I just edit the data_test.json file from

{ "lidar_to_sensor_transform": [-1, 0, 0, 0, 0, -1, 0, 0, 0, 0, 1, 36.180, 0, 0, 0, 1] }

to

{ "lidar_to_sensor_transform": [0, -1, 0, 0, 1, 0 , 0, 0, 0, 0, 1, 36.180, 0, 0, 0, 1] }

The above would set the rotation around the z-axis to 90 deg ccw.

Would this be correct?

Hi,
I'm using a RPi 4B 8Gb to receive data from an OS1-32. For the first few seconds I receive the whole pointcloud but then there is some black strips and I only receive the closest points on the pointcloud.

I've noticed that this depends of the lidar mode. It seems to depend of the number of points received. In 512x10 everything is fine but this problem happens when using 1024x10, 1024x20, 2048x10.
May be this is coming from the processing power, this is the %CPU it got with top command:

• 1024x10: 195%CPU
• 2048x10: 220%CPU

I've checked with my computer instead of the RPi and everything is fine in all lidar modes.

/opt/ros/melodic/lib/nodelet/nodelet: symbol lookup error: /home/nvidia/ouster_ws/devel/lib/libouster_ros.so: undefined symbol: _ZNK6ouster9LidarScan5fieldIjLj0EEEN5Eigen3RefIKNS2_5ArrayIT_Lin1ELin1ELi1ELin1ELin1EEELi0ENS2_8internal11conditionalIXsrS7_21IsVectorAtCompileTimeENS2_11InnerStrideILi1EEENS2_11OuterStrideILin1EEEE4typeEEENS_6sensor9ChanFieldE
[FATAL] [1674891721.774745183]: Failed to load nodelet '/ouster/os_cloud_nodeof typenodelets_os/OusterCloudto manageros_nodelet_mgr'
[FATAL] [1674891721.775106561]: Failed to load nodelet '/ouster/img_nodeof typenodelets_os/OusterImageto manageros_nodelet_mgr'
================================================================================REQUIRED process [ouster/os_nodelet_mgr-2] has died!
process has died [pid 2000, exit code 127, cmd bash -c sleep 2; $0 $@ /opt/ros/melodic/lib/nodelet/nodelet manager __name:=os_nodelet_mgr __log:=/home/nvidia/.ros/log/338c96dc-9edf-11ed-8353-00044bc4960c/ouster-os_nodelet_mgr-2.log].
log file: /home/nvidia/.ros/log/338c96dc-9edf-11ed-8353-00044bc4960c/ouster-os_nodelet_mgr-2*.log
Initiating shutdown!

board:nvidia jetson tx2
os:ubuntu 18.04
ros melodic

Hi, thank you for your work with ouster-ros.
I am using ouster OS-0-64 lidar to run my LIO algorithm. And I choose to use imu 3dm-gx5-25 instead of ouster imu. But when I run ouster.launch. The topic /os_cloud_node/points time stamp is not ros time. While my imu data time stamp is ros time. So I need to sync my lidar data and imu data by ros time. But I don't know how to get the lidar topic data with ros time.
Could you give me some advice about how to change the driver file. So I can get the points data with ros time.
Thank you.

If releasing ROS drivers, we need to select specific ouster_client headers to use. When multiple firmware versions are compatible with the same ouster_client, then we can support a range of firmwares within a same ROS distribution.

However when changes are needing to be made to ouster_client that make existing supported firmware versions within that distribution no longer compatible, then the new changes / firmwares need to be released in an upcoming ROS distribution.

Ex.

ouster_client before november supported all 1.x versions and we released the drivers for Kinetic / Melodic / Foxy. All 1.x's are supported. However since the ouster_client changed and no longer supports 1.x versions, that change can only be made in future ROS distribution releases (e.g. Noetic, Galactic) and those distributions will then only support 2.x+ firmware versions.

So we need to come up with a strategy / a table of what distributions are going to support what version ranges and plan out ouster_client better so that in the future firmware releases don't break older versions, if possible.

I want the Ouster to have a destaggered (organized) Point Cloud published. As per the documentation located at https://static.ouster.dev/sdk-docs/reference/lidar-scan.html#staggering-and-destaggering, there is a function available for destaggering. However, I am unsure of where to implement it within the Ouster in order to obtain a destaggered point cloud.

My assumption is that the destaggering function needs to be called from within the scan_to_cloud_f function of the os_ros. But I am uncertain of the exact location within that function where the destaggering function should be integrated.
My guess is that it needs to be called inside the scan_to_cloud_f function of os_ros. But where exactly ?

Hi. I tried converting pcap to bag format. I tried generatating pointcloud information but there is no topic information for ros2. It shows error like this . Could you please help me out .Thanks in advance

I know the documentation describes the situation with frames quite extensively, but generally people expect that raw data from a sensor are published in the acquisition frame. That would be os_lidar. But the example ROS node transforms and publishes the data in os_sensor, which is rotated and shifted in Z.

One possible consequence of misinterpreting the frames is usage of the scans in a raytracing pipeline. These pipelines usually take the frame_id of the incoming scan and cast rays from the origin of the given frame. But if the frame is os_sensor, the cast rays are invalid because the origin is shifted lower than the real optical origin of the rays.

I thus suggest changing the data frame to os_lidar. Users who do not care about the origin of observation should not be affected (except receiving the data in a different frame), and users interested in the observation point would get the expected data by default.

I have multiple Ouster OS1-32D and OS0-64D devices. I want to receive multicast data from them on several computers, and publish point clouds using the ROS driver. Does the driver currently support multicast traffic?

I have configured the udp_dest parameter on my lidars, and I can see multicast traffic through the wireshark, but the driver does not publish messages. Are there any instructions for running the ROS driver via multicast messages?

I am attempting to use PTP to synchronize the OS1-64-U LiDAR with my Ubuntu 20.04 computer running ROS Noetic. I have been following this documentation (https://static.ouster.dev/sensor-docs/image_route1/image_route2/appendix/ptp-quickstart.html#), and also set timestamp_mode to TIME_FROM_PTP_1588 in the sensor.launch ROS launch file here https://github.com/ouster-lidar/ouster-ros/blob/master/launch/sensor.launch#L22; but that has not worked so far.

My system does have a GMR1000 grandmaster clock; however, I have temporarily disconnected it for simplicity, as I just want synchronization between the LiDAR and my computer for now. I have verified that the eno1 and enp2s0 ethernet ports/interfaces on my computer do have hardware and software support for PTP.

Before I provide details on my ptp4l, phc2sys, and/or phc2shm configuration(s), I want to clarify if I missed an important preliminary step - do I need to configure the LiDAR's timestamp_mode to TIME_FROM_PTP_1588 at the firmware level using TCP first? There seems to be some mention of this detail in https://static.ouster.dev/sensor-docs/image_route1/image_route2/time_sync/time-sync.html#time-synchronization and ouster-lidar/ouster_example#78 (comment). Or, does simply setting timestamp_mode to TIME_FROM_PTP_1588 in sensor.launch configure the firmware implicitly already?

Also, if this question is better suited for Ouster customer support, please let me know and I can make a ticket in https://ouster.atlassian.net/servicedesk/customer/portal/8/group/22/create/86 instead. Thanks!

Hello,

Thanks for the Ouster driver, it's works well! I would like to make one request, which is to my knowlesge, the user does not have any control over what fields the Ouster publishes. The driver will always publish X, Y, Z, intensity, t, reflectivity, ring, noise, and range. This is a lot of data that to most users is not necessary. In my specific application, I want XYZI because I am fusing the point cloud with XYZI point clouds from other depth sensors onboard a robot. Therefore, having the same PointType is convenient. I can envision other folks wanting to disable fields they don't need to reduce the amount of computational/communications resources required to run the driver.

In order to resolve this issue, I had to make changes to the driver source code (ouster_ros/include/ouster_ros/point_os1.h), which I would prefer to not do.

Thanks!

Gene

Hi, @kairenw
I came across this package by KumarRobotics.
It has very low latency (<0.2ms) compared to ouster_example (>3ms).
can we incorporate it into this standard driver package

thanks

This code and some other similar instances

makes an assumption about monotonically increasing timestamps in the lidar packets. However, that is not guaranteed.

For example, we discipline Ouster clock via PTP automotive profile which can move the clock pretty fast, including discrete time jumps in both directions.

What happens in the driver code is that the scan timestamp is taken as the first timestamp in the scan. However, subsequent timestamps may be smaller, the subtraction yields negative numbers, and the static_cast<uint32_t> returns values close to the max representable uint32_t as it underflows, which is somewhere around 4e9. That would mean some points in the scan were captured about 4 seconds after the time in header.stamp, which is of course nonsense.

Here is an example plot of the timestamps in a single scan that was affected by this bug:

There are several possibilities what can be done with such scans:

1. The simplest thing would be computing the scan timestamp as the minimum value of all timestamps - that would ensure that the subtraction result is always non-negative, however the timestamps would remain non-continuous and non-monotonic.
2. Another possibility is discarding the whole scan as damaged.
3. The best option could be trying to repair the timestamps. This is what I have implemented in our custom driver - figure out if there is only a single discrete jump in the timestamps, and if there is, offset the first n invalid values by the jump size, which would make the timestamps again continuous. The scan start time has to be recomputed afterwards.

I can imagine different use-cases will have different preferences about what to do in this case.

If you'd like, I can share the fix I did in our custom driver. However, first it would be good to figure out which approaches should be implemented in this driver.

Hi,

Are there any plans to release the APT packages for the ouster driver? :)

For ros:rolling, there is already published APT package ouster_msgs. Are there any plans to deal with that?

ros-drivers/ros2_ouster_drivers#131

Thanks for you work :)

Best regards Jitka Hodna

Hello, we are using the ROS the driver to obtain the point cloud data. For the the time synchronization we are using TIME_FROM_PTP_1588. We are wondering where the timestamp from the PointCloud2 message is coming from? Is it from the ptp synched sensor (e.g. start of the measurement process) or the timestamp when the message is received on the host machine, or is it the time after the ROS driver processed the packets?

This code takes the first valid timestamp in the scan as the timestamp of the whole scan. However, the usual understanding of header.stamp field is when the scan acquisition began. I understand that when the first packets are missing, this information is not exactly available. However, given the regularity and precision of the rotation motor in the lidar, the timestamp of column 0 could be very easily extrapolated. That would seem to me as a better solution.

Hi, I am trying to setup PTP time synchronization on RB5 dev kit. It has a USB3.0 to Ethernet interface, which is being for the LIDAR. I need some help with the following queries:

• The Software documentation states the following assumption:
  

• The ethernet interface that we have doesn't support Hardware timestamping. As shown here:
  
  Does it mean we cannot do time synchronization on our development board? What alternatives can we use?

• From what I've read, hardware sync is better that software sync in terms of accuracy. Correct me if I'm wrong.

2. To check the performance of time synchronization, I used

rostopoic delay /topic_name

utility. This compares the message header timestamp to the current ROS timestamp.
I collected following data:

delay in TIME_FROM_PTP_1588 mode over hardware interface: ~0.130
delay in TIME_FROM_PTP_1588 mode over software interface: ~0.350
delay in TIME_FROM_ROS_TIME mode: ~0.105

• How to figure out the amount of delay which suits my application?
• Is rostopic delay the correct way to compare? If not, what should I use?

3. Extending over 1st question. What's the accuracy loss when we shift to software timestamping supported time synchronization?

On ROS2 foxy, when build I got an error

ros2_ws/src/ouster-ros/ouster-ros/src/os_ros.cpp
fatal error: tf2_eigen/tf2_eigen.hpp: No such file or directory
18 | #include <tf2_eigen/tf2_eigen.hpp>

I checked the packages blow, but everything already installed.

sudo apt install -y
ros-foxy-pcl-ros
ros-foxy-tf2-eigen
ros-foxy-rviz2

I see in the sdk that we can convert a pcap to csv. But is there a way to do this and convert to a rosbag with sensor_msg/PointCloud2 and sensor_msg/imu msg format?
If not, how do we take the row by row extracted in the csv demo and extract the imu and lidar data separately?

Hi,
In continuation of the issue mentioned here I got in touch with the Ouster team and elaborated this issue as suggested by @kairenw, one of their suggestion was as follows

Ignore the azimuths/columns of measurement data that are near the shroud column edges. Maybe 2-3 columns on either side as an estimate.

How can I ignore specific azimuths/column in this driver as mentioned in the suggestion

thanks

Description: I was using ouster_ros as a catkin dependency in my own catkin project. It complains about no such file for the pcl include in ros.h. Looking at the cmakelist in ouster_ros, it seems like the pcl dependency is not exported in catkin_package.

Suggestion: either add pcl in catkin_package DEPENDS or just depend on pcl_ros

OS

• ubuntu 20.04

Ros

• noetic

information

The issue I am creating here, goes right along with the issue I created with the Ros2 driver repo (ros-drivers/ros2_ouster_drivers#95). But essentially, the ring data type is defined as a uint8_t and while this doesn't break anything, updating it to a uint16_t has the benefits of increasing the portability of both the Ros1 and Ros2 Ouster Drivers and allowing the users to create more reusable code because ignition gazebo and other 3D lidar drivers use a uint16_t as their ring datatype.
I already have this fix completed and ready to be tested when I get to my Ouster on Monday. I can also make PR with these changes so please let me know if i need to add anything!

Build fails with the below error

src/ouster-ros/ouster-sdk/ouster_client/src/image_processing.cpp:145:31:   required from here
/usr/local/include/eigen3/Eigen/src/Core/util/ForwardDeclarations.h:23:29: error: invalid use of incomplete type 'struct Eigen::internal::traits<double>'
   23 | template<typename T> struct traits<const T> : traits<T> {};
      |                             ^~~~~~~~~~~~~~~
/usr/local/include/eigen3/Eigen/src/Core/util/ForwardDeclarations.h:17:29: note: declaration of 'struct Eigen::internal::traits<double>'
   17 | template<typename T> struct traits;

looks like this is because of the below functions from src/ouster-ros/ouster-sdk/ouster_client/src/image_processing.cpp line #145

 // use overloads vs templates so implicit conversion to Eigen::Ref still works
void AutoExposure::operator()(Eigen::Ref<img_t<float>> image,
                              bool update_state) {
    update(image, update_state);
}

void AutoExposure::operator()(Eigen::Ref<img_t<double>> image,
                              bool update_state) {
    update(image, update_state);
}

The build is fine by commenting out the first function.

Eigen version : 3.3.7
gcc version: 9.4.0
Ubuntu 20.04

Hello,

Could you please provide an example ROS2 launch file for starting Ouster LiDAR in multi-casting mode so multiple processes can listen to the messages? My LiDAR model is OS1-64.

Thank you!

HI everyone,

I can access the topic /ouster/points and I can visualize on the RVIZ, but I want to use on Fast LIO and the topic /ouster/points don't subscriber at /laserMapping. I achieved to run command: rostopic hz /ouster/lidar_packets and rostopic hz /ouster/points

I have a question about Ouster driver handling for ROS. I was having an error in tf lookupTransform that the transform is old. Ouster driver publishing the tf is using ros time where as other sensor data like lidar and imu are using here and here.

I know Ouster can handle different timestamp methods, but I don't understand the reason of using it for sensor readings but not for tf.

HI everyone,

I can't access the topic /ouster/imu as a image, but the point cloud is working normally

Hi, I've got an OS1-128 using the latest version of the firmware. Running the ROS node at 2048x10 mode synced with a Jetson AGX via hardware PTP, the results of rostopic delay /os_cloud_node/points command start from around 0.140 sec, but over the course of about 10-15 mins slowly progress to 0.250~ (which feels like quite a lot) and then it seems like they kinda slowly fluctuate between the two. What are the possible reasons and is there a way to make the delay more stable?

Hi!

We use ouster-ros in our build process, and hadn't pinned a specific commit so our builds stopped working this morning.
After some time, we realized it was because you split this library out of the old repository (good change!), so I've been updating our builds but when I run catkin_make install, I get this error message:

file INSTALL cannot find "/root/catkin_ws/src/ouster-ros/../LICENSE".
Call Stack (most recent call first):
cmake_install.cmake:136 (include)

Makefile:73: recipe for target 'install' failed

I assume that there is some error in the CMakeLists.txt, maybe the ../ should be removed from ../LICENSE?

EDIT: LICENSE-bin doesn't exist in this repository either, so should that line be removed?

I ran this driver on DJI's onboard processor (manifold2), and the compilation was normal, but an error was reported after running.

What is the problem?

ubuntu16.04
ros: kinetic

`Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://manifold2:44993/

SUMMARY

PARAMETERS

• /os_cloud_node/tf_prefix:
• /os_node/imu_port: 0
• /os_node/lidar_mode:
• /os_node/lidar_port: 0
• /os_node/metadata: test.json
• /os_node/replay: False
• /os_node/sensor_hostname: 192.168.1.200
• /os_node/timestamp_mode:
• /os_node/udp_dest: 192.168.1.102
• /rosdistro: kinetic
• /rosversion: 1.12.17

NODES
/
os_cloud_node (ouster_ros/os_cloud_node)
os_node (ouster_ros/os_node)
relay_imu (topic_tools/relay)
relay_lidar (topic_tools/relay)
rviz (rviz/rviz)

auto-starting new master
process[master]: started with pid [2207]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 938df7a8-24c7-11ec-b841-34d262856487
process[rosout-1]: started with pid [2220]
started core service [/rosout]
process[os_node-2]: started with pid [2223]
process[os_cloud_node-3]: started with pid [2224]
process[relay_lidar-4]: started with pid [2225]
process[relay_imu-5]: started with pid [2226]
process[rviz-6]: started with pid [2227]
[ INFO] [1633320015.526410599]: Client version: 0.2.1+47f25ed-dirty-release
[ INFO] [1633320015.526503985]: Sending UDP data to 192.168.1.102
[ INFO] [1633320015.526530534]: Waiting for sensor 192.168.1.200 to initialize ...
[ INFO] [1633320025.376086189]: Sensor initialized successfully
[ INFO] [1633320025.377133979]: Wrote metadata to test.json
[ INFO] [1633320025.378396023]: Using lidar_mode: 1024x10
[ INFO] [1633320025.378510400]: OS-1-32-U2 sn: 122119000305 firmware rev: v2.0.0
*** Error in `/home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node': double free or corruption (out): 0x0000000001073aa0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7fd55effd7f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8038a)[0x7fd55f00638a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fd55f00a58c]
/home/dji/ouster32_ws/devel/lib/libouster_ros.so(_ZN10ouster_ros13scan_to_cloudERKN6ouster6XYZLutENSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEERKNS0_9LidarScanERN3pcl10PointCloudINS_5PointEEE+0x270)[0x7fd5605fbf60]
/home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node[0x409011]
/home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node(_ZN3ros27SubscriptionCallbackHelperTIRKN10ouster_ros10PacketMsg_ISaIvEEEvE4callERNS_36SubscriptionCallbackHelperCallParamsE+0x2e6)[0x40ed56]
/opt/ros/kinetic/lib/libroscpp.so(_ZN3ros17SubscriptionQueue4callEv+0xadd)[0x7fd5600ebc8d]
/opt/ros/kinetic/lib/libroscpp.so(_ZN3ros13CallbackQueue9callOneCBEPNS0_3TLSE+0x4b0)[0x7fd5600919e0]
/opt/ros/kinetic/lib/libroscpp.so(_ZN3ros13CallbackQueue13callAvailableENS_12WallDurationE+0x54b)[0x7fd56009341b]
/opt/ros/kinetic/lib/libroscpp.so(_ZN3ros21SingleThreadedSpinner4spinEPNS_13CallbackQueueE+0x2a9)[0x7fd5600efd39]
/opt/ros/kinetic/lib/libroscpp.so(_ZN3ros4spinEv+0x2b)[0x7fd5600d4d8b]
/home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node(main+0xf10)[0x408050]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fd55efa6840]
/home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node(_start+0x29)[0x408b29]
======= Memory map: ========
00400000-00414000 r-xp 00000000 08:02 6179611 /home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node
00613000-00614000 r--p 00013000 08:02 6179611 /home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node
00614000-00615000 rw-p 00014000 08:02 6179611 /home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node
00f42000-01154000 rw-p 00000000 00:00 0 [heap]
7fd544000000-7fd544021000 rw-p 00000000 00:00 0
7fd544021000-7fd548000000 ---p 00000000 00:00 0
7fd548000000-7fd548021000 rw-p 00000000 00:00 0
7fd548021000-7fd54c000000 ---p 00000000 00:00 0
7fd54c000000-7fd54c021000 rw-p 00000000 00:00 0
7fd54c021000-7fd550000000 ---p 00000000 00:00 0
7fd552ffe000-7fd552fff000 ---p 00000000 00:00 0
7fd552fff000-7fd5537ff000 rw-p 00000000 00:00 0
7fd5537ff000-7fd553800000 ---p 00000000 00:00 0
7fd553800000-7fd554000000 rw-p 00000000 00:00 0
7fd554000000-7fd554021000 rw-p 00000000 00:00 0
7fd554021000-7fd558000000 ---p 00000000 00:00 0
7fd55849d000-7fd5586df000 rw-p 00000000 00:00 0
7fd5586df000-7fd5586e0000 ---p 00000000 00:00 0
7fd5586e0000-7fd558ee0000 rw-p 00000000 00:00 0
7fd558ee0000-7fd558ee1000 ---p 00000000 00:00 0
7fd558ee1000-7fd5596e1000 rw-p 00000000 00:00 0
7fd5596e1000-7fd5596ec000 r-xp 00000000 08:02 1324750 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7fd5596ec000-7fd5598eb000 ---p 0000b000 08:02 1324750 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7fd5598eb000-7fd5598ec000 r--p 0000a000 08:02 1324750 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7fd5598ec000-7fd5598ed000 rw-p 0000b000 08:02 1324750 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7fd5598ed000-7fd5598f3000 rw-p 00000000 00:00 0
7fd5598f3000-7fd55b1a9000 r-xp 00000000 08:02 6183 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7fd55b1a9000-7fd55b3a8000 ---p 018b6000 08:02 6183 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7fd55b3a8000-7fd55b3a9000 r--p 018b5000 08:02 6183 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7fd55b3a9000-7fd55b3aa000 rw-p 018b6000 08:02 6183 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7fd55b3aa000-7fd55b3d0000 r-xp 00000000 08:02 1315564 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fd55b3d0000-7fd55b5d0000 ---p 00026000 08:02 1315564 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fd55b5d0000-7fd55b5d2000 r--p 00026000 08:02 1315564 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fd55b5d2000-7fd55b5d3000 rw-p 00028000 08:02 1315564 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fd55b5d3000-7fd55b5dc000 r-xp 00000000 08:02 1324743 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7fd55b5dc000-7fd55b7db000 ---p 00009000 08:02 1324743 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7fd55b7db000-7fd55b7dc000 r--p 00008000 08:02 1324743 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7fd55b7dc000-7fd55b7dd000 rw-p 00009000 08:02 1324743 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7fd55b7dd000-7fd55b80b000 rw-p 00000000 00:00 0
7fd55b80b000-7fd55b80e000 r-xp 00000000 08:02 1312472 /lib/x86_64-linux-gnu/libdl-2.23.so
7fd55b80e000-7fd55ba0d000 ---p 00003000 08:02 1312472 /lib/x86_64-linux-gnu/libdl-2.23.so
7fd55ba0d000-7fd55ba0e000 r--p 00002000 08:02 1312472 /lib/x86_64-linux-gnu/libdl-2.23.so
7fd55ba0e000-7fd55ba0f000 rw-p 00003000 08:02 1312472 /lib/x86_64-linux-gnu/libdl-2.23.so
7fd55ba0f000-7fd55ba13000 r-xp 00000000 08:02 1315490 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fd55ba13000-7fd55bc12000 ---p 00004000 08:02 1315490 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fd55bc12000-7fd55bc13000 r--p 00003000 08:02 1315490 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fd55bc13000-7fd55bc14000 rw-p 00004000 08:02 1315490 /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fd55bc14000-7fd55bd93000 r-xp 00000000 08:02 6177 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7fd55bd93000-7fd55bf93000 ---p 0017f000 08:02 6177 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7fd55bf93000-7fd55bfa3000 r--p 0017f000 08:02 6177 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7fd55bfa3000-7fd55bfa4000 rw-p 0018f000 08:02 6177 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7fd55bfa4000-7fd55bfa8000 rw-p 00000000 00:00 0
7fd55bfa8000-7fd55c1fa000 r-xp 00000000 08:02 6181 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7fd55c1fa000-7fd55c3fa000 ---p 00252000 08:02 6181 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7fd55c3fa000-7fd55c409000 r--p 00252000 08:02 6181 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7fd55c409000-7fd55c40a000 rw-p 00261000 08:02 6181 /usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7fd55c40a000-7fd55c430000 r-xp 00000000 08:02 7079 /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0.5.4
7fd55c430000-7fd55c62f000 ---p 00026000 08:02 7079 /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0.5.4
7fd55c62f000-7fd55c630000 r--p 00025000 08:02 7079 /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0.5.4
7fd55c630000-7fd55c631000 rw-p 00026000 08:02 7079 /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0.5.4
7fd55c631000-7fd55c662000 r-xp 00000000 08:02 7074 /usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2
7fd55c662000-7fd55c861000 ---p 00031000 08:02 7074 /usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2
7fd55c861000-7fd55c862000 r--p 00030000 08:02 7074 /usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2
7fd55c862000-7fd55c863000 rw-p 00031000 08:02 7074 /usr/lib/x86_64-linux-gnu/libapr-1.so.0.5.2
7fd55c863000-7fd55c867000 r-xp 00000000 08:02 7394 /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2
7fd55c867000-7fd55ca66000 ---p 00004000 08:02 7394 /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2
7fd55ca66000-7fd55ca67000 r--p 00003000 08:02 7394 /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2
7fd55ca67000-7fd55ca68000 rw-p 00004000 08:02 7394 /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2
7fd55ca68000-7fd55ca6f000 r-xp 00000000 08:02 1324757 /lib/x86_64-linux-gnu/librt-2.23.so
7fd55ca6f000-7fd55cc6e000 ---p 00007000 08:02 1324757 /lib/x86_64-linux-gnu/librt-2.23.so
7fd55cc6e000-7fd55cc6f000 r--p 00006000 08:02 1324757 /lib/x86_64-linux-gnu/librt-2.23.so
7fd55cc6f000-7fd55cc70000 rw-p 00007000 08:02 1324757 /lib/x86_64-linux-gnu/librt-2.23.so
7fd55cc70000-7fd55cd73000 r-xp 00000000 08:02 7267 /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.58.0
7fd55cd73000-7fd55cf73000 ---p 00103000 08:02 7267 /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.58.0
7fd55cf73000-7fd55cf77000 r--p 00103000 08:02 7267 /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.58.0
7fd55cf77000-7fd55cf78000 rw-p 00107000 08:02 7267 /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.58.0
7fd55cf78000-7fd55d127000 r-xp 00000000 08:02 8236 /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10.0.0
7fd55d127000-7fd55d326000 ---p 001af000 08:02 8236 /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10.0.0
7fd55d326000-7fd55d34c000 r--p 001ae000 08:02 8236 /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10.0.0
7fd55d34c000-7fd55d34d000 rw-p 001d4000 08:02 8236 /usr/lib/x86_64-linux-gnu/liblog4cxx.so.10.0.0
7fd55d34d000-7fd55d34f000 rw-p 00000000 00:00 0
7fd55d34f000-7fd55d350000 r-xp 00000000 08:02 2098917 /opt/ros/kinetic/lib/librosconsole_backend_interface.so
7fd55d350000-7fd55d54f000 ---p 00001000 08:02 2098917 /opt/ros/kinetic/lib/librosconsole_backend_interface.so
7fd55d54f000-7fd55d550000 r--p 00000000 08:02 2098917 /opt/ros/kinetic/lib/librosconsole_backend_interface.so
7fd55d550000-7fd55d551000 rw-p 00001000 08:02 2098917 /opt/ros/kinetic/lib/librosconsole_backend_interface.so
7fd55d551000-7fd55d567000 r-xp 00000000 08:02 2098918 /opt/ros/kinetic/lib/librosconsole_log4cxx.so
7fd55d567000-7fd55d767000 ---p 00016000 08:02 2098918 /opt/ros/kinetic/lib/librosconsole_log4cxx.so
7fd55d767000-7fd55d769000 r--p 00016000 08:02 2098918 /opt/ros/kinetic/lib/librosconsole_log4cxx.so
7fd55d769000-7fd55d76a000 rw-p 00018000 08:02 2098918 /opt/ros/kinetic/lib/librosconsole_log4cxx.so
7fd55d76a000-7fd55d781000 r-xp 00000000 08:02 7200 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
7fd55d781000-7fd55d980000 ---p 00017000 08:02 7200 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
7fd55d980000-7fd55d981000 r--p 00016000 08:02 7200 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
7fd55d981000-7fd55d982000 rw-p 00017000 08:02 7200 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0
7fd55d982000-7fd55d988000 r-xp 00000000 08:02 7187 /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.58.0
7fd55d988000-7fd55db88000 ---p 00006000 08:02 7187 /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.58.0
7fd55db88000-7fd55db89000 r--p 00006000 08:02 7187 /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.58.0
7fd55db89000-7fd55db8a000 rw-p 00007000 08:02 7187 /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.58.0
7fd55db8a000-7fd55db91000 r-xp 00000000 08:02 2099389 /opt/ros/kinetic/lib/libcpp_common.so
7fd55db91000-7fd55dd90000 ---p 00007000 08:02 2099389 /opt/ros/kinetic/lib/libcpp_common.so
7fd55dd90000-7fd55dd91000 r--p 00006000 08:02 2099389 /opt/ros/kinetic/lib/libcpp_common.so
7fd55dd91000-7fd55dd92000 rw-p 00007000 08:02 2099389 /opt/ros/kinetic/lib/libcpp_common.so
7fd55dd92000-7fd55ddb0000 r-xp 00000000 08:02 2098939 /opt/ros/kinetic/lib/libxmlrpcpp.so
7fd55ddb0000-7fd55dfaf000 ---p 0001e000 08:02 2098939 /opt/ros/kinetic/lib/libxmlrpcpp.so
7fd55dfaf000-7fd55dfb0000 r--p 0001d000 08:02 2098939 /opt/ros/kinetic/lib/libxmlrpcpp.so
7fd55dfb0000-7fd55dfb1000 rw-p 0001e000 08:02 2098939 /opt/ros/kinetic/lib/libxmlrpcpp.so
7fd55dfb1000-7fd55dfc9000 r-xp 00000000 08:02 1324738 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fd55dfc9000-7fd55e1c8000 ---p 00018000 08:02 1324738 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fd55e1c8000-7fd55e1c9000 r--p 00017000 08:02 1324738 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fd55e1c9000-7fd55e1ca000 rw-p 00018000 08:02 1324738 /lib/x86_64-linux-gnu/libpthread-2.23.so
7fd55e1ca000-7fd55e1ce000 rw-p 00000000 00:00 0
7fd55e1ce000-7fd55e1f2000 r-xp 00000000 08:02 7280 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
7fd55e1f2000-7fd55e3f1000 ---p 00024000 08:02 7280 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
7fd55e3f1000-7fd55e3f3000 r--p 00023000 08:02 7280 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
7fd55e3f3000-7fd55e3f4000 rw-p 00025000 08:02 7280 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
7fd55e3f4000-7fd55e426000 r-xp 00000000 08:02 2098326 /opt/ros/kinetic/lib/libtf2.so
7fd55e426000-7fd55e625000 ---p 00032000 08:02 2098326 /opt/ros/kinetic/lib/libtf2.so
7fd55e625000-7fd55e627000 r--p 00031000 08:02 2098326 /opt/ros/kinetic/lib/libtf2.so
7fd55e627000-7fd55e628000 rw-p 00033000 08:02 2098326 /opt/ros/kinetic/lib/libtf2.so
7fd55e628000-7fd55e646000 r-xp 00000000 08:02 2101712 /opt/ros/kinetic/lib/libactionlib.so
7fd55e646000-7fd55e845000 ---p 0001e000 08:02 2101712 /opt/ros/kinetic/lib/libactionlib.so
7fd55e845000-7fd55e847000 r--p 0001d000 08:02 2101712 /opt/ros/kinetic/lib/libactionlib.so
7fd55e847000-7fd55e848000 rw-p 0001f000 08:02 2101712 /opt/ros/kinetic/lib/libactionlib.so
7fd55e848000-7fd55e950000 r-xp 00000000 08:02 1324741 /lib/x86_64-linux-gnu/libm-2.23.so
7fd55e950000-7fd55eb4f000 ---p 00108000 08:02 1324741 /lib/x86_64-linux-gnu/libm-2.23.so
7fd55eb4f000-7fd55eb50000 r--p 00107000 08:02 1324741 /lib/x86_64-linux-gnu/libm-2.23.so
7fd55eb50000-7fd55eb51000 rw-p 00108000 08:02 1324741 /lib/x86_64-linux-gnu/libm-2.23.so
7fd55eb51000-7fd55eb81000 r-xp 00000000 08:02 8182 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.2
7fd55eb81000-7fd55ed80000 ---p 00030000 08:02 8182 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.2
7fd55ed80000-7fd55ed81000 r--p 0002f000 08:02 8182 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.2
7fd55ed81000-7fd55ed82000 rw-p 00030000 08:02 8182 /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1.7.2
7fd55ed82000-7fd55ed85000 r-xp 00000000 08:02 7276 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
7fd55ed85000-7fd55ef84000 ---p 00003000 08:02 7276 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
7fd55ef84000-7fd55ef85000 r--p 00002000 08:02 7276 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
7fd55ef85000-7fd55ef86000 rw-p 00003000 08:02 7276 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0
7fd55ef86000-7fd55f146000 r-xp 00000000 08:02 1324737 /lib/x86_64-linux-gnu/libc-2.23.so
7fd55f146000-7fd55f346000 ---p 001c0000 08:02 1324737 /lib/x86_64-linux-gnu/libc-2.23.so
7fd55f346000-7fd55f34a000 r--p 001c0000 08:02 1324737 /lib/x86_64-linux-gnu/libc-2.23.so
7fd55f34a000-7fd55f34c000 rw-p 001c4000 08:02 1324737 /lib/x86_64-linux-gnu/libc-2.23.so
7fd55f34c000-7fd55f350000 rw-p 00000000 00:00 0
7fd55f350000-7fd55f367000 r-xp 00000000 08:02 1311176 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd55f367000-7fd55f566000 ---p 00017000 08:02 1311176 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd55f566000-7fd55f567000 r--p 00016000 08:02 1311176 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd55f567000-7fd55f568000 rw-p 00017000 08:02 1311176 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fd55f568000-7fd55f73b000 r-xp 00000000 08:02 661 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fd55f73b000-7fd55f93b000 ---p 001d3000 08:02 661 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fd55f93b000-7fd55f946000 r--p 001d3000 08:02 661 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fd55f946000-7fd55f949000 rw-p 001de000 08:02 661 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
7fd55f949000-7fd55f94c000 rw-p 00000000 00:00 0
7fd55f94c000-7fd55f977000 r-xp 00000000 08:02 2098527 /opt/ros/kinetic/lib/librostime.so
7fd55f977000-7fd55fb76000 ---p 0002b000 08:02 2098527 /opt/ros/kinetic/lib/librostime.so
7fd55fb76000-7fd55fb78000 r--p 0002a000 08:02 2098527 /opt/ros/kinetic/lib/librostime.so
7fd55fb78000-7fd55fb79000 rw-p 0002c000 08:02 2098527 /opt/ros/kinetic/lib/librostime.so
7fd55fb79000-7fd55fb7b000 r-xp 00000000 08:02 2098518 /opt/ros/kinetic/lib/libroscpp_serialization.so
7fd55fb7b000-7fd55fd7a000 ---p 00002000 08:02 2098518 /opt/ros/kinetic/lib/libroscpp_serialization.so
7fd55fd7a000-7fd55fd7b000 r--p 00001000 08:02 2098518 /opt/ros/kinetic/lib/libroscpp_serialization.so
7fd55fd7b000-7fd55fd7c000 rw-p 00002000 08:02 2098518 /opt/ros/kinetic/lib/libroscpp_serialization.so
7fd55fd7c000-7fd55fdab000 r-xp 00000000 08:02 2098916 /opt/ros/kinetic/lib/librosconsole.so
7fd55fdab000-7fd55ffab000 ---p 0002f000 08:02 2098916 /opt/ros/kinetic/lib/librosconsole.so
7fd55ffab000-7fd55ffad000 r--p 0002f000 08:02 2098916 /opt/ros/kinetic/lib/librosconsole.so
7fd55ffad000-7fd55ffae000 rw-p 00031000 08:02 2098916 /opt/ros/kinetic/lib/librosconsole.so
7fd55ffae000-7fd560137000 r-xp 00000000 08:02 2101684 /opt/ros/kinetic/lib/libroscpp.so
7fd560137000-7fd560336000 ---p 00189000 08:02 2101684 /opt/ros/kinetic/lib/libroscpp.so
7fd560336000-7fd56033c000 r--p 00188000 08:02 2101684 /opt/ros/kinetic/lib/libroscpp.so
7fd56033c000-7fd560340000 rw-p 0018e000 08:02 2101684 /opt/ros/kinetic/lib/libroscpp.so
7fd560340000-7fd5603e6000 r-xp 00000000 08:02 2098344 /opt/ros/kinetic/lib/libtf2_ros.so
7fd5603e6000-7fd5605e6000 ---p 000a6000 08:02 2098344 /opt/ros/kinetic/lib/libtf2_ros.so
7fd5605e6000-7fd5605ea000 r--p 000a6000 08:02 2098344 /opt/ros/kinetic/lib/libtf2_ros.so
7fd5605ea000-7fd5605ec000 rw-p 000aa000 08:02 2098344 /opt/ros/kinetic/lib/libtf2_ros.so
7fd5605ec000-7fd560626000 r-xp 00000000 08:02 6179600 /home/dji/ouster32_ws/devel/lib/libouster_ros.so
7fd560626000-7fd560826000 ---p 0003a000 08:02 6179600 /home/dji/ouster32_ws/devel/lib/libouster_ros.so
7fd560826000-7fd560827000 r--p 0003a000 08:02 6179600 /home/dji/ouster32_ws/devel/lib/libouster_ros.so
7fd560827000-7fd560828000 rw-p 0003b000 08:02 6179600 /home/dji/ouster32_ws/devel/lib/libouster_ros.so
7fd560828000-7fd56084e000 r-xp 00000000 08:02 1324748 /lib/x86_64-linux-gnu/ld-2.23.so
7fd560868000-7fd560929000 rw-p 00000000 00:00 0
7fd5609ec000-7fd560a0b000 rw-p 00000000 00:00 0
7fd560a3a000-7fd560a4d000 rw-p 00000000 00:00 0
7fd560a4d000-7fd560a4e000 r--p 00025000 08:02 1324748 /lib/x86_64-linux-gnu/ld-2.23.so
7fd560a4e000-7fd560a4f000 rw-p 00026000 08:02 1324748 /lib/x86_64-linux-gnu/ld-2.23.so
7fd560a4f000-7fd560a50000 rw-p 00000000 00:00 0
7fff7b374000-7fff7b396000 rw-p 00000000 00:00 0 [stack]
7fff7b3de000-7fff7b3e1000 r--p 00000000 00:00 0 [vvar]
7fff7b3e1000-7fff7b3e3000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
================================================================================REQUIRED process [os_cloud_node-3] has died!
process has died [pid 2224, exit code -6, cmd /home/dji/ouster32_ws/devel/lib/ouster_ros/os_cloud_node ~/os_config:=/os_node/os_config ~/lidar_packets:=/os_node/lidar_packets ~/imu_packets:=/os_node/imu_packets __name:=os_cloud_node __log:=/home/dji/.ros/log/938df7a8-24c7-11ec-b841-34d262856487/os_cloud_node-3.log].
log file: /home/dji/.ros/log/938df7a8-24c7-11ec-b841-34d262856487/os_cloud_node-3*.log
Initiating shutdown!

[rviz-6] killing on exit
[relay_imu-5] killing on exit
[relay_lidar-4] killing on exit
[os_cloud_node-3] killing on exit
[os_node-2] killing on exit
[ INFO] [1633320026.071683232]: poll_client: caught signal, exiting
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done`

Hi!
Thank you for your effort with the ros2 rolling driver for the ouster. I am happy to test it, and I have some doubts and ideas to share. :)

I setup the config file with this setting:

  ros__parameters:
    sensor_hostname: '10.64.1.6'
    udp_dest: '10.64.1.5'
    lidar_mode: '1024x10'
    timestamp_mode: 'TIME_FROM_ROS_TIME'
    udp_profile_lidar: ''
    metadata: ''
    lidar_port: 7502
    imu_port: 7503
ouster/os_cloud:
  ros__parameters:
    tf_prefix: ''
    timestamp_mode: '

And launched

ros2 launch ouster_ros sensor.composite.launch.py

Everything looks fine :)

I tried to integrate it to my robot, and I set in my urdf file the link os_sensor according to this (the whole urdf is in the attachment)
model.txt

<link name="os_sensor">
    <inertial>
      <mass value="1.1797214877679865"/>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <inertia ixx="0.0010891778635817933" ixy="0.0" ixz="0.0" iyy="0.0010891778635817933" iyz="0.0" izz="0.0011161639926144861"/>
    </inertial>
    <visual>
      <geometry>
        <mesh filename="file:///home/hodnajit/rtabmap_experiments/install/optimus_description/share/optimus_description/meshes/sensors/ouster_os0.stl" scale="0.001 0.001 0.001"/>
      </geometry>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <material name="yellow"/>
    </visual>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 0"/>
      <geometry>
        <mesh filename="file:///home/hodnajit/rtabmap_experiments/install/optimus_description/share/optimus_description/meshes/sensors/ouster_os0.stl" scale="0.001 0.001 0.001"/>
      </geometry>
    </collision>
  </link>
  <joint name="ouster_joint" type="fixed">
    <origin rpy="0 0.06283 0" xyz="0 0 0.9175"/>
    <child link="os_sensor"/>
    <parent link="base_link"/>
  </joint>

I launch it
ros2 launch ouster_ros sensor.composite.launch.py viz:=False

I have no problem with tf if I visualisate it in frame base_footprint

(see the fixed_frame set to base_footprint and Pointcloud2 to topic /ouster/points)

But if I change the view to /odom or /map frame, it says there is no transform between /odom (or /map) to /os_imu or /os_lidar and I cannot see the pointcloud

What am I doing wrong? I tried to add the transforms os_imu and os_lidar into urdf file as well, but the result was the same :/. And I can see, there is a tf publisher in os_cloud

tf_bcast.sendTransform(ouster_ros::transform_to_tf_msg(
            info.imu_to_sensor_transform, sensor_frame, imu_frame, msg_ts));

and

tf_bcast.sendTransform(ouster_ros::transform_to_tf_msg(
            info.lidar_to_sensor_transform, sensor_frame, lidar_frame, msg_ts));

So it looks to me that I do not need to publish the transform between sensor_frame and lidar(or imu)_frame. It looks good if I printed the transform with ros2 run tf2_tools view_frames.
frames.pdf

Can you add the setting of sensor_frame as parameter? Or maybe the imu_frame and the lidar_frame as well? Or how does it work?

Thank you very much,

Best regards

Jitka Hodna

Hi,

Right now if we do "roslaunch sensor.launch" and if the sensor is not connected to the systems (lets say it was not powered on), then the launch file crashes.
Is there a way to retry instead of crashing? The launch file is used with other sensor (like a camera, imu etc) and crashing of this file causes the whole system to crash.

I'm trying out the new ros2 branch just mentioned here.
##50 (comment)

Looking at the PointCloud in Rviz2, it is visible that the PointCloud is not updating at the 10Hz rate expected when running in the 1024x10 mode.
Running ros2 topic hz on the /ouster/points topic shows this as well.

However, the images appear to be updating at 10Hz as expected.

I'm using an OS2-64 connected directly to a NUC 12. Ubuntu 22.04 ROS Humble.
Let me know if there any anything I can try to get the PointCloud publishing at 10Hz and help out.