ros2 / demos Goto Github PK

License: Apache License 2.0

CMake 7.95% C++ 64.11% Python 25.66% C 2.29%

demos's Introduction

About

The Robot Operating System (ROS) is a set of software libraries and tools that help you build robot applications. From drivers to state-of-the-art algorithms, and with powerful developer tools, ROS has what you need for your next robotics project. And it's all open source. Full project details on ROS.org

Getting Started

Looking to get started with ROS? Our installation guide is here. Once you've installed ROS start by learning some basic concepts and take a look at our beginner tutorials.

Join the ROS Community

Community Resources

ROS Discussion Forum
ROS Discord Server
Robotics Stack Exchange (preferred ROS support forum).
Official ROS Videos
ROSCon, our yearly developer conference.
Cite ROS 2 in academic work using DOI: 10.1126/scirobotics.abm6074

Developer Resources

ROS 2 Documentation
ROS Package API reference
ROS Package Index
ROS on Docker Hub
ROS Resource Status Page
REP-2000: ROS 2 Releases and Target Platforms

Project Resources

ROS is made possible through the generous support of open source contributors and the non-profit Open Source Robotics Foundation (OSRF). Tax deductible donations to the OSRF can be made here.

demos's People

Contributors

Stargazers

Watchers

Forkers

erlerobot dhood rohbotics alex031544 ros2-tw sarcasm clalancette mkhansenbot chenjie2017 theosakamg decourier kukanani oursland fmrico youtalk gavanderhoorn lucasw cbhust thogit gbiggs hiryu26 dbergin yihongyishui anasarrak aarushg22 testkit esteve eprosima kev-the-dev t0ny-peng itfanr arianajdari erzen7 milomeng song-ms josephduchesne sgvandijk gonzodepedro wxxhub samiamlabs b2220333 hilarobotican emersonknapp rossizero xiexiaozheng ipa-rar robotis-move bluefox19 pankhurivanjani xiaonaiquan mike-moore aws-ros-dev jubeira roverrobotics-forks kerliang0801 malcom-neo orduno alsora mugekural9 mikaelarguedas davidmansolino ericztoa sgermanserrano fujitatomoya deepa1996 ipa-vsp sreevis pbaughman dabonnie 0000duck qingxi2020 pylotlight airuchen viplav04 zhouchengming99 nwachukwucobinna wanglu119 danbmh yueyeah gleke tsukuyomih2 elephantjohn puck-fzi mhaboali iamrajee joequan gyuhooo shanhx2000 5l1v3r1 thebyohazard tleyssens dodsonmg ashwinsushil iuhilnehc-ynos joelloo ivanpauno shotaak dmamx33 jayhou kenyn

demos's Issues

Multiple clients or servers in composition seems to be flaky

Bug report

I'm currently using Ardent pre-release on ARM64 Linux, with the single-RMW Fast-RTPS implementation. I'm following the testing guide here. If I load up a single Server and Client into the same composition, things work fine. If I load up a Server and multiple clients into the same composition, then arbitrary-seeming things happen. In one case, the server started spewing something about an "Invalid sequence number". In another case, I couldn't successfully shutdown the composition node. And in a third case, everything worked just fine.

Required Info:

Operating System:
- Ubuntu 16.04 on ARM64
Installation type:
- Fat binary, Fast-RTPS-only build
Version or commit hash:
- demos git hash 40e09c1
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

In terminal one:

ros2 run composition api_composition

In terminal two:

ros2 run composition api_composition_cli -- composition composition::Server
ros2 run composition api_composition_cli -- composition composition::Client
ros2 run composition api_composition_cli -- composition composition::Client

Expected behavior

With a single Server and two Clients, it seems like they should just happily alternate getting results from the server.

Actual behavior

Somewhat different results every time, ranging from server not being ready to being unable to shut down the composition node, to working just fine.

no stdout output from parameter_events using connext

Bug report

Required Info:

Operating System:
- Windows 10
Installation type:
- binaries
Version or commit hash:
- https://ci.ros2.org/view/packaging/job/packaging_windows/1046/
DDS implementation:
- RTI Connext
Client library (if applicable):
- N/A

Steps to reproduce issue

set RMW_IMPLEMENTATION=rmw_connext_cpp
ros2 run demo_nodes_cpp parameter_events

Expected behavior

Should print text about parameters

[INFO] [parameter_events]:
Parameter event:
 new parameters:
  foo
 changed parameters:
 deleted parameters:

[INFO] [parameter_events]:
Parameter event:
 new parameters:
  bar
 changed parameters:
 deleted parameters:

[INFO] [parameter_events]:
Parameter event:
 new parameters:
  baz
 changed parameters:
 deleted parameters:

[INFO] [parameter_events]:
Parameter event:
 new parameters:
  foobar
 changed parameters:
 deleted parameters:

[INFO] [parameter_events]:
Parameter event:
 new parameters:
 changed parameters:
  foo
 deleted parameters:

[INFO] [parameter_events]:
Parameter event:
 new parameters:
 changed parameters:
  bar
 deleted parameters:

Actual behavior

Prints license message and exits

>ros2 run demo_nodes_cpp parameter_events
RTI Data Distribution Service Evaluation License issued to OSRF (OSRF01) [email protected] For non-production use only.
Expires on 5-Nov-2018 See www.rti.com for more information.

Additional information

The expected behavior occurs using fastrtps and opensplice. parameter_events_async with connext also works fine.

demos should print reasonable error message when no camera is present

Currently camera_node and image_pipeline_* just crash without any notice (on Windows). cam2image e.g. prints an error message (Could not open video stream) which is the desired behavior.

move topic_monitor executables in package specific path

Similar to #136.

Remove references to shared pointers

References to shared pointers cause issues with the lifetime of pointers, which have exposed bugs in certain parts of our code (e.g. services).

cam2image__rmw_connext_cpp fails

Running showimage in another terminal, if I start cam2image I get the error:

Publishing image #1
COMMENDSrWriterService_write:!write. Reliable large data requires asynchronous writer.
PRESPsWriter_writeInternal:!srw->write
terminate called after throwing an instance of 'std::runtime_error'
  what():  failed to publish message: failed to publish message, at /home/jackie/code/ros2_ws/src/ros2/rmw_connext/rmw_connext_cpp/src/functions.cpp:410
Aborted (core dumped)

Building demo_nodes_cpp_native and rmw_fastrtps_cpp in same workspace fails because of wrong include directory

I'm building on Ubuntu 16.04 with ROS2 beta3.

Download and installROS2 beta3 to /opt.
mkdir -p ~/ros2_ws/src && cd ~/ros2_ws/src
git clone https://github.com/ros2/demos
git clone https://github.com/ros2/rmw_fastrtps
modify ~/ros2_ws/src/rmw_fastrtps/rmw_fastrtps_cpp/include/get_participant.hpp and add the function "foo()".
modify ~/ros2_ws/src/demos/demo_nodes_cpp_native/src/talker.cpp to call "foo()".
cd ~/ros2_ws
source /opt/ros2-linux/local_setup.bash
ament build -j1

The build fails with the complain that "foo()" cannot be found when compiling talker.cpp. It turns out that this is because it is compiling with /opt/ros2-linux/include/rmw_fastrtps_cpp/get_participant.hpp and not ~/ros2_ws/install/include/rmw_fastrtps_cpp/get_participant.hpp which has my change. If I look at the depends.make file for talker, it's only including files for rmw_fastrtps_cpp from /opt/ros2-linux.

I can't figure out how to get the demos_cpp_native package in my workspace to look at the rmw_fastrtps_cpp package in my workspace.

composition test_api_pubsub_composition with rmw_fastrtps flaky on xenial

In the composition package the test test_api_pubsub_composition is flaky when using rmw_fastrtps. When run repeatedly, the test will fail within 1 to 3 minutes.

When the bug occurs:

messages from the publisher are printed to the console window, but no message from the subscriber is ever printed
Messages from the publisher are successfully echo'd using ros2 topic echo
Messages published using ros2 topic pub after the bug occurs are either never received by the subscriber, or always received by the subscriber. It seems like there are two kinds failures: one where the subscriber never talks to any publisher, and one where it won't talk to a publisher in the same process.

Output from wireshark during a failing test (starts at message number 25732)
ros2_composition_pubsub_fail.pcapng.zip

The following expect script can reproduce the issue (save as pubsubfail.exp). The comment at the top can be copy/pasted into bash. It will run the test over and over until the bug is observed, then send SIGINT to drop into a gdb prompt.

# while expect pubsubfail.exp $(ros2 pkg executables --full-path composition | grep api_composition\$) ; do date; done

set CTRLC \003
set timeout 10
set api_composition_path [lindex $argv 0]

spawn ros2 run composition api_composition_cli composition composition::Talker
spawn ros2 run composition api_composition_cli composition composition::Listener
spawn gdb -quiet -ex run $api_composition_path

expect {
  "I heard" exit
  timeout {
    send $CTRLC
    interact
  }
}

I've been unable to reduce the code. I have only gotten the failure to occur when the talker and listener nodes are loaded in a service callback.

cover all demos with unit tests

Follow up to ros2/ros2#143

showimage demo fails with OpenSplice

On Linux and OS X the test fails:

On Windows it fails to compile:

http://ci.ros2.org/job/ci_windows/1659/console

Build failed at dummy_robot/dummy_sensors/src/dummy_joint_states.cpp

From master, on Debian (Testing).

when build dummy_sensor report : Full Log

Process package 'dummy_sensors' with context:
--------------------------------------------------------------------------------
 source_space => .../src/ros2/demos/dummy_robot/dummy_sensors
  build_space => .../build_isolated/dummy_sensors
install_space => .../install_isolated/dummy_sensors
   make_flags => -j4, -l4
  build_tests => True
--------------------------------------------------------------------------------
+++ Building 'dummy_sensors'
Running cmake because arguments have changed.
==> '. .../build_isolated/dummy_sensors/cmake__build.sh && /usr/bin/cmake .../src/ros2/demos/dummy_robot/dummy_sensors -DBUILD_TESTING=1 -DAMENT_CMAKE_SYMLINK_INSTALL=1 -DCMAKE_INSTALL_PREFIX=.../install_isolated/dummy_sensors' in '.../build_isolated/dummy_sensors'
-- Found ament_cmake: 0.0.0 (.../ament_ws/install_isolated/ament_cmake/share/ament_cmake/cmake)
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Override CMake install command with custom implementation using symlinks instead of copying resources
-- Found rclcpp: 0.0.0 (.../install_isolated/rclcpp/share/rclcpp/cmake)
-- Found rmw_implementation_cmake: 0.0.0 (.../install_isolated/rmw_implementation_cmake/share/rmw_implementation_cmake/cmake)
-- Found sensor_msgs: 0.0.0 (.../install_isolated/sensor_msgs/share/sensor_msgs/cmake)
-- Found ament_lint_auto: 0.0.0 (.../ament_ws/install_isolated/ament_lint_auto/share/ament_lint_auto/cmake)
-- Added test 'copyright' to check for copyright in CMake / C / C++ / Python code
-- Added test 'cppcheck' to perform static code analysis on C / C++ code
-- Added test 'cpplint' to check C / C++ code against the Google style
-- Added test 'lint_cmake' to check CMake code style
-- Added test 'uncrustify' to check C / C++ code style
-- Configuring done
-- Generating done
-- Build files have been written to: .../build_isolated/dummy_sensors
==> '. .../build_isolated/dummy_sensors/cmake__build.sh && /usr/bin/make -j4 -l4' in '.../build_isolated/dummy_sensors'
[ 25%] Building CXX object CMakeFiles/dummy_joint_states.dir/src/dummy_joint_states.cpp.o
[ 75%] Built target dummy_laser
.../src/ros2/demos/dummy_robot/dummy_sensors/src/dummy_joint_states.cpp: In function ‘int main(int, char**)’:
.../src/ros2/demos/dummy_robot/dummy_sensors/src/dummy_joint_states.cpp:44:19: error: ‘sin’ is not a member of ‘std’
     joint_value = std::sin(counter);
                   ^~~

If i add in file : dummy_robot/dummy_sensors/src/dummy_joint_states.cpp

#include <math.h>

Not sure of solution but all work fine.

strange overwritten error with

For example on my machine, while testing alpha 6:

% two_node_pipeline__rmw_fastrtps_cpp
[rmw|error_handling.c:93] error string being overwritten: not implemented, at /Users/william/ros2_ws/src/eProsima/ROS-RMW-Fast-RTPS-cpp/rmw_fastrtps_cpp/src/functions.cpp:1768
Published message with value: 0, and address: 0x7FFA898004B0
 Received message with value: 0, and address: 0x7FFA898004B0
Published message with value: 1, and address: 0x7FFA885AE6D0
 Received message with value: 1, and address: 0x7FFA885AE6D0
Published message with value: 2, and address: 0x7FFA885AE6D0
 Received message with value: 2, and address: 0x7FFA885AE6D0
Published message with value: 3, and address: 0x7FFA885AE6D0
 Received message with value: 3, and address: 0x7FFA885AE6D0
^Csignal_handler(2)

It is because of this nonsense that I had in the fastrtps function to get the graph guard condition:

https://github.com/eProsima/ROS-RMW-Fast-RTPS-cpp/blob/master/rmw_fastrtps_cpp/src/functions.cpp#L1768-L1769

I'm working on a fix.

topic_monitor: should use unbuffered output

The launch files should start the various Python processes with PYTHONUNBUFFERED=1 in order to show the output on the fly.

r2b3 Lifecycle python client fails to start

moved from ros2/ros2#404

Bug report

Required Info:

Operating System:
- Windows 10
Installation type:
- http://ci.ros2.org/view/packaging/job/packaging_windows/728/artifact/ws/ros2-package-windows-AMD64.zip
Version or commit hash:
- def304b4270b6b935b7d6fbbf7671634c2532452
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclpy

Steps to reproduce issue

Source local_setup.bat and run this command (from this tutorial)

ros2 run lifecycle lifecycle_service_client_py.py

Expected behavior

usage: lifecycle_service_client_py.py [-h]
                                      [--change-state-args {configure,cleanup,shutdown,activate,deactivate}]
                                      {change_state,get_state,get_available_states,get_available_transitions}
                                      node

Actual behavior

C:\Users\osrf>ros2 run lifecycle lifecycle_service_client_py.py
Traceback (most recent call last):
  File "C:\dev\ros2\Scripts\ros2-script.py", line 11, in <module>
    load_entry_point('ros2cli==0.0.0', 'console_scripts', 'ros2')()
  File "C:\dev\ros2\Lib\site-packages\ros2cli\cli.py", line 64, in main
    rc = extension.main(parser=parser, args=args)
  File "C:\dev\ros2\Lib\site-packages\ros2run\command\run.py", line 73, in main
    return run_executable(path=path, argv=args.argv, prefix=prefix)
  File "C:\dev\ros2\Lib\site-packages\ros2run\api\__init__.py", line 55, in run_executable
    completed_process = subprocess.run(cmd)
  File "C:\Python36\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Python36\lib\subprocess.py", line 707, in __init__
    restore_signals, start_new_session)
  File "C:\Python36\lib\subprocess.py", line 992, in _execute_child
    startupinfo)
OSError: [WinError 193] %1 is not a valid Win32 application

Additional information

Same error if I drop the .py

C:\Users\osrf>ros2 run lifecycle lifecycle_service_client_py
Traceback (most recent call last):
  File "C:\dev\ros2\Scripts\ros2-script.py", line 11, in <module>
    load_entry_point('ros2cli==0.0.0', 'console_scripts', 'ros2')()
  File "C:\dev\ros2\Lib\site-packages\ros2cli\cli.py", line 64, in main
    rc = extension.main(parser=parser, args=args)
  File "C:\dev\ros2\Lib\site-packages\ros2run\command\run.py", line 73, in main
    return run_executable(path=path, argv=args.argv, prefix=prefix)
  File "C:\dev\ros2\Lib\site-packages\ros2run\api\__init__.py", line 55, in run_executable
    completed_process = subprocess.run(cmd)
  File "C:\Python36\lib\subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Python36\lib\subprocess.py", line 707, in __init__
    restore_signals, start_new_session)
  File "C:\Python36\lib\subprocess.py", line 992, in _execute_child
    startupinfo)
OSError: [WinError 193] %1 is not a valid Win32 application

topic_monitor launch_reliability_demo hangs on exit on Windows

Bug report

Required Info:

Operating System:
- Windows 10
Installation type:
- from source
Version or commit hash:
- vcs export --exact: https://gist.github.com/wjwwood/9e6106e70e8ce624be165c26fa5cfbb1
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- N/A

Steps to reproduce issue

Run:

ros2 run topic_monitor launch_reliability_demo

Or:

.\install\Lib\topic_monitor\launch_reliability_demo.exe

Expected behavior

Ends cleanly when ctrl-c.

Actual behavior

Hangs on ctrl-c.

Additional information

Works as expected on Linux and macOS, and other launch scripts seem to work on Windows.

Trying to get the state of lifecycle listener hangs forever

Bug report

I'm running the tutorial at https://github.com/ros2/ros2/wiki/managed-nodes#run-the-demo on Linux ARM64 with the Fast-RTPS only fat archive. If I run the lifecycle_talker, then try get_state with lifecycle_service_client_py.py, I get the correct state. If I then run lifecycle_listener, and try to get the state using lifecycle_service_client_py.py, it hangs forever. When I eventually hit Ctrl-C, it throws a traceback:

^CTraceback (most recent call last):
  File "/home/ubuntu/ros2-linux/lib/lifecycle/lifecycle_service_client_py.py", line 125, in <module>
    main(args.service, args.node, args.change_state_args)
  File "/home/ubuntu/ros2-linux/lib/lifecycle/lifecycle_service_client_py.py", line 104, in main
    get_state(lifecycle_node)
  File "/home/ubuntu/ros2-linux/lib/lifecycle/lifecycle_service_client_py.py", line 58, in get_state
    % (lifecycle_node, cli.response.current_state.label, cli.response.current_state.id))
AttributeError: 'NoneType' object has no attribute 'current_state'
Exception ignored in: <bound method Node.__del__ of <rclpy.node.Node object at 0x7fa6622860>>
Traceback (most recent call last):
  File "/home/ubuntu/ros2-linux/lib/python3.5/site-packages/rclpy/node.py", line 300, in __del__
    self.destroy_node()
  File "/home/ubuntu/ros2-linux/lib/python3.5/site-packages/rclpy/node.py", line 275, in destroy_node
    _rclpy.rclpy_destroy_node_entity(cli.client_handle, self.handle)
RuntimeError: Failed to fini 'rcl_client_t': rcl node is invalid, rcl instance id does not match, at /home/rosbuild/ci_scripts/ws/src/ros2/rcl/rcl/src/rcl/node.c:382

Required Info:

Operating System:
- Ubuntu 16.04 ARM64
Installation type:
- Fast-RTPS-only fat archive
Version or commit hash:
- c44e525 of demos repo
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp/rclpy

Steps to reproduce issue

Terminal 1:

ros2 run lifecycle lifecycle_talker

Terminal 2:

ros2 run lifecycle lifecycle_listener

Terminal 3:

ros2 run lifecycle lifecycle_service_client_py.py -- get_state lc_listener

Expected behavior

Should be able to get the current lifecycle state of lc_listener.

Actual behavior

The call to lifecycle_service_client_py.py hangs forever. If I Ctrl-C, I get the stacktrace above.

pendulum_control: fails to build

@jacquelinekay this package doesn't build:

-- Build files have been written to: /home/victor/ros2_ws/build/pendulum_control
==> '. /home/victor/ros2_ws/build/pendulum_control/cmake__build.sh && /usr/bin/make -j3 -l3' in '/home/victor/ros2_ws/build/pendulum_control'
[ 50%] [100%] Building CXX object CMakeFiles/pendulum_demo__rmw_opensplice_cpp.dir/src/pendulum_demo.cpp.o
Building CXX object CMakeFiles/pendulum_demo.dir/src/pendulum_demo.cpp.o
Linking CXX executable pendulum_demo
Linking CXX executable pendulum_demo__rmw_opensplice_cpp
/usr/bin/ld: CMakeFiles/pendulum_demo__rmw_opensplice_cpp.dir/src/pendulum_demo.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [pendulum_demo__rmw_opensplice_cpp] Error 1
make[1]: *** [CMakeFiles/pendulum_demo__rmw_opensplice_cpp.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/usr/bin/ld: CMakeFiles/pendulum_demo.dir/src/pendulum_demo.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [pendulum_demo] Error 1
make[1]: *** [CMakeFiles/pendulum_demo.dir/all] Error 2
make: *** [all] Error 2

Tried adding -lpthread erlerobot@ea77763 but doesn't seem to help. Any ideas?

Intra-process communication latency

Bug report

Required Info:

Operating System:
- Ubuntu 16.04
Installation type:
-from source
Version or commit hash:
- 0.5.1
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

I slightly modified the demos/intra_process_demo/src/two_node_pipeline/two_node_pipeline.cpp example.

Changing the message type to something "bigger" such as

std_msgs/Header header
byte[4096] array

Moreover I recorded the communication latency as the difference between the timestamp in the message header and the current time when the subscriber callback is triggered.

Expected behavior

Intra-Process communication avoids copying object around and just share a pointer, thus reducing latency.

Actual behavior

When use_intra_process_comms is set to true in the node constructors, the average latency is almost identical or even slightly bigger.

showimage could not deserialize message when cam2image interrupted

Bug report

Required Info:

Operating System:
- Windows 10
Installation type:
- binaries
Version or commit hash:
- https://ci.ros2.org/view/packaging/job/packaging_windows/1042/
DDS implementation:
- RTI Connext
Client library (if applicable):
- N/A

Steps to reproduce issue

In one terminal

set RMW_IMPLEMENTATION=rmw_connext_cpp
ros2 run image_tools showimage

in another

set RMW_IMPLEMENTATION=rmw_connext_cpp
ros2 run image_tools cam2image -b

Then in the cam2image terminal hit CTRL + c

Expected behavior

showimage would stop receiving images and nothing would be printed to the console.

Actual behavior

showimage executable outputs this message when cam2image is stopped.

cdr stream doesn't contain data
deserialize from cdr buffer failed
[ERROR] [rclcpp]: could not deserialize serialized message on topic '/image': can't convert cdr stream to ros message, at C:\J\workspace\packaging_windows\ws\src\ros2\rmw_connext\rmw_connext_cpp\src\rmw_take.cpp:185, at C:\J\workspace\packaging_windows\ws\src\ros2\rcl\rcl\src\rcl\subscription.c:258

Additional information

Not sure if this belongs here or in the rmw_connext_cpp repo

image_pipeline_all_in_one doesn't work with FastRTPS

The CameraNode is publishing images but the WatermarkNode never receives any messages. As a consequence the image view GUI is not even shown.

The problem is the same even when the use_intra_process_comms flag is set to false for the three nodes.

With Connext and OpenSplice the demo works flawless.

two_node_pipeline demo has consumer / producer swapped

I was doing the IPC tutorial and noticed the two_node_pipeline has a minor bug. In the code, it is setting the names of the consumer & producer to the opposite object.
auto producer = std::make_shared<Producer>("consumer", "number");
auto consumer = std::make_shared<Consumer>("producer", "number");

I'm happy to submit the 2 line PR to fix this if you want. I don't know if you want external PRs at this point.

[lifecycle] installed python files are not executable

They are in bin, but not executable and so which doesn't find them:

% which lifecycle_listener
/tmp/testing_beta1/ros2-osx/bin/lifecycle_listener
% which lifecycle_demo_launch.py
lifecycle_demo_launch.py not found

However, this is how the user is recommended to execute them:

python3 `which lifecycle_service_client_py.py`
-- https://github.com/ros2/ros2/wiki/Managed-Nodes

Not sure if this works on Linux as-is, but it doesn't work with zsh on OS X (my machine).

don't generate pendulum_logger_results.csv in source space

Either generate it somewhere else or add it to the .gitignore file. Also each rmw impl. specific test overwrites the file.

move lifecycle executables in package specific path

Similar to #136.

Small depth of pendulum demo causes Connext output

Occasionally (36 of the past 100 "repeated" nightlies) the pendulum control demo has Connext output that disrupts the output checks of the tests.

e.g. http://ci.ros2.org/view/nightly/job/nightly_linux_repeated/624/testReport/junit/(root)/test_pendulum__rmw_connext_cpp/test_executable/

Example output ([b'Initial major pagefaults: 0', b'Initial minor pagefaults: 8625', b'PRESWriterHistoryDriver_completeBeAsynchPub:!make_sample_reclaimable', b'rttest statistics:', b'  - Minor pagefaults: 36', b'  - Major pagefaults: 0', b'  Latency (time after deadline was missed):', b'    - Min: 17403 ns', b'    - Max: 16213992 ns', b'    - Mean: 284679 ns', b'    - Standard deviation: 685.729', b'', b'', b'PendulumMotor received 242 messages', b'PendulumController received 245 messages']) does not match expected output ([b'Initial major pagefaults: \\d+', b'Initial minor pagefaults: \\d+', b'rttest statistics:', b'  - Minor pagefaults: \\d+', b'  - Major pagefaults: \\d+', b'  Latency \\(time after deadline was missed\\):', b'    - Min: \\d+ ns', b'    - Max: \\d+ ns', b'    - Mean: \\d+.\\d+ ns', b'    - Standard deviation: \\d+(\\.\\d+)?(e[\\+\\-]\\d+)?', b'', b'', b'PendulumMotor received \\d+ messages', b'PendulumController received \\d+ messages'])
-------------------- >> begin captured stdout << ---------------------
(test_executable_0) pid 10880: ['/home/rosbuild/ci_scripts/ws/build/pendulum_control/pendulum_logger'] (InMemoryHandler: test_executable_0, all > console)
(test_executable_1) pid 10881: ['/home/rosbuild/ci_scripts/ws/build/pendulum_control/pendulum_demo', '-i', '1000'] (InMemoryHandler: test_executable_1, all > console)
[test_executable_0] RTI Data Distribution Service Evaluation License issued to OSRF - OSRF01 [email protected] For non-production use only.
[test_executable_0] Expires on 06-may-2017 See www.rti.com for more information.
[test_executable_0] Logger node initialized.
[test_executable_0] Commanded motor angle: 1.570796
[test_executable_0] Actual motor angle: 0.000000
[test_executable_0] Current latency: 17403 ns
[test_executable_0] Mean latency: 115539.344924 ns
[test_executable_0] Min latency: 17403 ns
[test_executable_0] Max latency: 180199 ns
[test_executable_0] Minor pagefaults during execution: 18
[test_executable_0] Major pagefaults during execution: 0
[test_executable_0] 
[test_executable_0] signal_handler(2)
(test_executable_0) rc 0
[test_executable_1] RTI Data Distribution Service Evaluation License issued to OSRF - OSRF01 [email protected] For non-production use only.
[test_executable_1] Expires on 06-may-2017 See www.rti.com for more information.
[test_executable_1] RTI Data Distribution Service Evaluation License issued to OSRF - OSRF01 [email protected] For non-production use only.
[test_executable_1] Expires on 06-may-2017 See www.rti.com for more information.
[test_executable_1] Initial major pagefaults: 0
[test_executable_1] Initial minor pagefaults: 8625
[test_executable_1] PRESWriterHistoryDriver_completeBeAsynchPub:!make_sample_reclaimable
[test_executable_1] rttest statistics:
[test_executable_1]   - Minor pagefaults: 36
[test_executable_1]   - Major pagefaults: 0
[test_executable_1]   Latency (time after deadline was missed):
[test_executable_1]     - Min: 17403 ns
[test_executable_1]     - Max: 16213992 ns
[test_executable_1]     - Mean: 284679 ns
[test_executable_1]     - Standard deviation: 685.729
[test_executable_1] 
[test_executable_1] 
[test_executable_1] PendulumMotor received 242 messages
[test_executable_1] PendulumController received 245 messages
(test_executable_1) rc 0

This page says that the PRESWriterHistoryDriver_completeBeAsynchPub:!make_sample_reclaimable output can come from using too small a depth.

Is it reasonable to increase the depth despite this comment on why it was set to 1? Otherwise we can alter the output checks, or alter the logging probably.

Windows binaries are built with debug symbols

CallbackReturn does not name a type

Bug report

Required Info:

Operating System:
- Ubuntu 18.04
Installation type:
- Binaries
Version or commit hash:
- 79b0aa0
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

Pull and execute colcon build

Expected behavior

Demos build

Actual behavior

Get multiple errors of the form

/home/jacob/ros2_ws/src/demos/lifecycle/src/lifecycle_talker.cpp:106:62: error: ‘CallbackReturn’ in ‘class rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface’ does not name a type
   rclcpp_lifecycle::node_interfaces::LifecycleNodeInterface::CallbackReturn

Parameter changes give "take response failed for client of service" errors

If I have a parameter_node running, then it spits out errors when I run the parameter_events demo in another terminal.

OS X with only Connext 5.2.3, using master.

Terminal A:

$ ros2 run demo_nodes_cpp parameter_node
RTI Data Distribution Service EVAL License issued to OSRF [email protected] For non-production use only.
Expires on 09-Oct-2017 See www.rti.com for more information.

Terminal B (expected output):

$ ros2 run demo_nodes_cpp parameter_events
RTI Data Distribution Service EVAL License issued to OSRF [email protected] For non-production use only.
Expires on 09-Oct-2017 See www.rti.com for more information.
Parameter event:
 new parameters:
  foo
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  bar
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  baz
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  foobar
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
 changed parameters:
  foo
 deleted parameters:
Parameter event:
 new parameters:
 changed parameters:
  bar
 deleted parameters:

Terminal A:

<already started>
[rclcpp::error] take response failed for client of service 'parameter_node/get_parameters': error not set, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279
[rclcpp::error] take response failed for client of service 'parameter_node/get_parameter_types': error not set, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279
[rclcpp::error] take response failed for client of service 'parameter_node/set_parameters': error not set, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279
[rclcpp::error] take response failed for client of service 'parameter_node/describe_parameters': error not set, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279
[rclcpp::error] take response failed for client of service 'parameter_node/list_parameters': error not set, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279, at /Users/dhood/ros2_ws_beta3/src/ros2/rcl/rcl/src/rcl/client.c:279
Parameter event:
 new parameters:
  foo
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  bar
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  baz
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
  foobar
 changed parameters:
 deleted parameters:
Parameter event:
 new parameters:
 changed parameters:
  foo
 deleted parameters:
Parameter event:
 new parameters:
 changed parameters:
  bar
 deleted parameters:

Is the on_parameter_event callback supposed to get notified of changes to other nodes?

Listener does not see msg when Talker publishes once

I'm seeing an issue where listener has a high chance of missing the first msg published to the topic.
I have FastRTPS.

This is a problem for the project I'm working on, in which I need to have a node that publishes once

Here is what I see when I run Talker and Listener.

Listener prints:
I heard: [Hello World: 2]
I heard: [Hello World: 3]
Talker prints:
Publishing: 'Hello World: 1'
Publishing: 'Hello World: 2'
Publishing: 'Hello World: 3'

Occasionally Listener does hear all the msgs Talker sends out. But if Talker is executed again while Listener is kept running, Listener misses the first msg again.

Composition examples require network availability to run

[I'm not sure if this is a bug or just not implemented yet but the documentation is nonetheless ambiguous.]

Problem
The composition examples (https://github.com/ros2/ros2/wiki/Composition) all require network access to run.

Expectation
Even though the documentation suggests that messages being published/subscribed to in the same process will be automatically copied (or a pointer passed depending), the underlying DDS is still used to perform the communication and so network access is required to run the examples.

Environment
Tested on MacOS 10.11.6 with ROS2 Beta1 compiled from source.

Tests
Tested the following with/without network access and with/without multi-cast loopback through localhost:
api_composition
manual_composition

Questions
Other code which does not yet appear to be documented seems to hint at solving (or at least trying to solve) this issue by specifying a bool use_intra_process_comms flag (e.g. src/ros2/rclcpp/rclcpp/include/rclcpp/create_publisher.hpp). If we inherit all our nodes from LifecycleNode, for example, will the intra-process memory copies(pointer passing) "just work"?

As an aside, which node type is the preferred one to inherit from? Node (as in most of the examples)? LifecycleNode? Something else?

Launch file for lifecycle_demo_launch.py should be converted to new-style launch

Bug report

Required Info:

Operating System:
- Ubuntu Bionic arm64
Installation type:
- Fat archive from 2018-06-21, downloaded from here: https://ci.ros2.org/view/packaging/job/packaging_linux-aarch64/475/artifact/ws/ros2-package-linux-aarch64.tar.bz2
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

$ ros2 launch ./share/lifecycle/launch/lifecycle_demo_launch.py

Expected behavior

The lifecycle demo launches.

Actual behavior

Traceback (most recent call last):
  File "/root/ros2-linux/bin/ros2", line 11, in <module>
    load_entry_point('ros2cli==0.4.0', 'console_scripts', 'ros2')()
  File "/root/ros2-linux/lib/python3.6/site-packages/ros2cli/cli.py", line 69, in main
    rc = extension.main(parser=parser, args=args)
  File "/root/ros2-linux/lib/python3.6/site-packages/ros2launch/command/launch.py", line 78, in main
    debug=args.debug
  File "/root/ros2-linux/lib/python3.6/site-packages/ros2launch/api/api.py", line 122, in launch_a_python_launch_file
    launch_description = get_launch_description_from_python_launch_file(python_launch_file_path)
  File "/root/ros2-linux/lib/python3.6/site-packages/ros2launch/api/api.py", line 109, in get_launch_description_from_python_launch_file
    python_launch_file_path, 'generate_launch_description()'
ros2launch.api.api.InvalidPythonLaunchFileError: launch file at './share/lifecycle/launch/lifecycle_demo_launch.py' does not contain the required function 'generate_launch_description()'

topic_monitor test seems to fail with debian packages

I'm testing out the debian packages on ARM64, and I started following these instructions: https://github.com/ros2/demos/blob/master/topic_monitor/README.md . However, the very first instruction to run ros2 run topic_monitor topic_monitor -- --display ends up in a traceback:

Traceback (most recent call last):
  File "/opt/ros/r2b2/lib/topic_monitor/topic_monitor", line 9, in <module>
    load_entry_point('topic-monitor==0.0.0', 'console_scripts', 'topic_monitor')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 542, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2569, in load_entry_point
    return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2229, in load
    return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2235, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ImportError: No module named 'topic_monitor'

Tutorial for QoS demo

api composition demo test is flakey

See this failure for example:

http://ci.ros2.org/job/nightly_linux-aarch64_repeated/57/testReport/(root)/projectroot/test_composition__rmw_fastrtps_cpp/

(test_api_composition) pid 32385: ['/home/rosbuild/ci_scripts/ws/build/composition/api_composition'] (all > console, InMemoryHandler: test_api_composition)
(load_talker_component) pid 32386: ['/home/rosbuild/ci_scripts/ws/build/composition/api_composition_cli', 'composition', 'composition::Talker'] (stderr > stdout, all > console)
(load_listener_component) pid 32387: ['/home/rosbuild/ci_scripts/ws/build/composition/api_composition_cli', 'composition', 'composition::Listener'] (stderr > stdout, all > console)
[load_listener_component] Sending request...
[load_listener_component] Waiting for response...
[load_listener_component] Result of load_node: success = true
(load_listener_component) rc 0
[test_api_composition] Load library /home/rosbuild/ci_scripts/ws/build/composition/liblistener_component.so
[test_api_composition] Instantiate class composition::Listener
[test_api_composition] I heard: [Hello World: 58]
[test_api_composition] signal_handler(2)
(test_api_composition) rc 0
() tear down
(load_talker_component) signal SIGINT
[load_talker_component] api_composition_cli was interrupted. Exiting.
[load_talker_component] Sending request...
[load_talker_component] Waiting for response...
[load_talker_component] signal_handler(2)
(load_talker_component) rc 1

This is what is happening, in my opinion:

test_api_composition starts and launch is looking for I heard: [Hello World: before assuming success of the test and sending sigint
load_listener_component loads the listener into the "container" test_api_composition, is successful and exits clean
load_talker_component also loads the talker into the container, but does not exit right away
the talker and listener talk with each other, launch notices and sends everyone sigint (success!)
but since load_talker_component isn't "done" yet (has not received the service response yet) the sigint it receives is interpreted as an error

Possible solution:

change launch to wait on sending sigint until it sees I heard: [Hello World: and Result of load_node: success = true two times

I don't know how to do that off hand, and I don't have time to follow up on it right now, but maybe sometime this week or next while I'm still build cop.

If anyone has any idea about how to make launch do what I described above, let me know.

what use of resource file?

I wonder the use of resource file " demos/demo_nodes_py/resource/demo_nodes_py
" when I build my package, because it did nothing. And how to remove it if it's not necessary ?

add_two_ints in python and c++ should have the same behaviour

the c++ server stays upe and the client sends only one request at a tine
the python server shuts down after 3 requests and the client send them by 3-request batches

FAST-RTPS Assertion error with image_tools with fastrtps and connext

Bug report

Required Info:

Operating System:
- OSX Sierra, 10.12.6
Installation type:
- source
Version or commit hash:
- master
DDS implementation:
- rmw_connext_cpp vs rmw_fastrtps_cpp

Steps to reproduce issue

First terminal:

RMW_IMPLEMENTATION=rmw_connext_cpp ros2 run image_tools showimage

Second terminal:

RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run image_tools cam2image

Expected behavior

No crash. Image tools are transporting images. The excepted behavior should the same when only using fastrtps.

Actual behavior

A few images are getting transported. However, fastrtps node cam2image crashes with assertion error:

...
[INFO] [cam2image]: Publishing image #221
[INFO] [cam2image]: Publishing image #222
[INFO] [cam2image]: Publishing image #223
Assertion failed: (*sn <= change->getDataFragments()->size()), function add_change, file /Users/karsten/workspace/osrf/ros2_full/src/eProsima/Fast-RTPS/src/cpp/rtps/writer/../flowcontrol/../writer/RTPSWriterCollector.h, line 83.

Handle KeyboardInterrupt in Python nodes

Feature request

Python demos output would be much cleaner if a stacktrace is not printed when a KeyboardInterrupt is thrown.

Quality of service demos in python

Context:
The image_tools demo is used in the “Use quality-of-service settings to handle lossy networks” tutorial. This demo currently only exists for C++. We have since added a python client library for ROS 2.

To do:

Replicate the image_tools demo using the python client library.
- using a webcam
- using synthetic images (useful for running automated tests without having a camera present)
Incorporate it into the quality of service tutorial.

Pointers:

This PR has examples of using different QoS profiles in python nodes: https://github.com/ros2/examples/pull/132/files
This OpenCV tutorial shows how to show images in python: http://docs.opencv.org/3.0-beta/doc/py_tutorials/py_gui/py_image_display/py_image_display.html
This C++ image_tools demo shows how to list a dependency on OpenCV:

demos/image_tools/package.xml

Line 11 in 16c3bc5

<build_depend>libopencv-dev</build_depend>

pendulum_demo sometimes hanging forever

The test test_pendulum_teleop sometimes hangs forever and therefore the test times out. After reproducing this locally with RMW_IMPLEMENTATION=rmw_connext_cpp python3 build_isolated/pendulum_control/test_pendulum_teleop__rmw_connext_cpp.py I was able to look at the stack:

#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f8b6d906dbd in __GI___pthread_mutex_lock (mutex=0x7f8b6c46fc00 <Poco::SharedLibraryImpl::_mutex>) at ../nptl/pthread_mutex_lock.c:80
#2  0x00007f8b6c153a98 in Poco::MutexImpl::lockImpl (this=0x7f8b6c46fc00 <Poco::SharedLibraryImpl::_mutex>) at include/Poco/Mutex_POSIX.h:81
#3  0x00007f8b6c153c86 in Poco::FastMutex::lock (this=0x7f8b6c46fc00 <Poco::SharedLibraryImpl::_mutex>) at include/Poco/Mutex.h:205
#4  0x00007f8b6c1544c0 in Poco::ScopedLock<Poco::FastMutex>::ScopedLock (this=0x7ffc2fe659b0, mutex=...) at include/Poco/ScopedLock.h:59
#5  0x00007f8b6c1bf5e8 in Poco::SharedLibraryImpl::findSymbolImpl (this=0xf39ba8, name="rmw_trigger_guard_condition") at src/SharedLibrary_UNIX.cpp:100
#6  0x00007f8b6c1bf8a1 in Poco::SharedLibrary::hasSymbol (this=0xf39ba0, name="rmw_trigger_guard_condition") at src/SharedLibrary.cpp:93
#7  0x00007f8b6c680839 in get_symbol (symbol_name=0x7f8b6c681f70 "rmw_trigger_guard_condition") at ../ws_ros2/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:148
#8  0x00007f8b6c681076 in rmw_trigger_guard_condition (guard_condition=0xf80e00) at ../ws_ros2/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:423
#9  0x00007f8b6e360963 in rcl_trigger_guard_condition (guard_condition=0x171e4a8) at ../ws_ros2/src/ros2/rcl/rcl/src/rcl/guard_condition.c:154
#10 0x00007f8b6e0c9c8d in trigger_interrupt_guard_condition (signal_value=2) at ../ws_ros2/src/ros2/rclcpp/rclcpp/src/rclcpp/utilities.cpp:115
#11 0x00007f8b6e0c9dc7 in signal_handler (signal_value=2, siginfo=0x7ffc2fe65cf0, context=0x7ffc2fe65bc0) at ../ws_ros2/src/ros2/rclcpp/rclcpp/src/rclcpp/utilities.cpp:158
#12 <signal handler called>
#13 0x00007f8b6c1bf5f8 in Poco::SharedLibraryImpl::findSymbolImpl (this=0xf39ba8, name="rmw_wait") at src/SharedLibrary_UNIX.cpp:103
#14 0x00007f8b6c1bf8a1 in Poco::SharedLibrary::hasSymbol (this=0xf39ba0, name="rmw_wait") at src/SharedLibrary.cpp:93
#15 0x00007f8b6c680839 in get_symbol (symbol_name=0x7f8b6c681fb3 "rmw_wait") at ../ws_ros2/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:148
#16 0x00007f8b6c68114d in rmw_wait (subscriptions=0x7f8b239fb908, guard_conditions=0x7f8b239fb920, services=0x7f8b239fb950, clients=0x7f8b239fb938, waitset=0x1f122f0, wait_timeout=0x7ffc2fe66450)
    at ../ws_ros2/src/ros2/rmw_implementation/rmw_implementation/src/functions.cpp:456
#17 0x00007f8b6e36b06a in rcl_wait (wait_set=0x1f12878, timeout=0) at ../ws_ros2/src/ros2/rcl/rcl/src/rcl/wait.c:590
#18 0x00007f8b6e021f98 in rclcpp::executor::Executor::wait_for_work (this=0x1f12860, timeout=...) at ../ws_ros2/src/ros2/rclcpp/rclcpp/src/rclcpp/executor.cpp:409
#19 0x00007f8b6e0231db in rclcpp::executor::Executor::get_next_executable (this=0x1f12860, timeout=...) at ../ws_ros2/src/ros2/rclcpp/rclcpp/src/rclcpp/executor.cpp:544
#20 0x00007f8b6e020b7e in rclcpp::executor::Executor::spin_some (this=0x1f12860) at ../ws_ros2/src/ros2/rclcpp/rclcpp/src/rclcpp/executor.cpp:191
#21 0x000000000042124f in pendulum_control::RttExecutor::loop_callback (arg=0x1f12860) at ../ws_ros2/src/ros2/demos/pendulum_control/include/pendulum_control/rtt_executor.hpp:135
#22 0x00007f8b6db2f821 in Rttest::spin_once (this=0xf35a48, user_function=0x4211f5 <pendulum_control::RttExecutor::loop_callback(void*)>, args=0x1f12860, start_time=0x7ffc2fe66750, update_period=0xf35a50, i=1145)
    at ../ws_ros2/src/ros2/realtime_support/rttest/src/rttest.cpp:595
#23 0x00007f8b6db2f576 in Rttest::spin_period (this=0xf35a48, user_function=0x4211f5 <pendulum_control::RttExecutor::loop_callback(void*)>, args=0x1f12860, update_period=0xf35a50, iterations=0)
    at ../ws_ros2/src/ros2/realtime_support/rttest/src/rttest.cpp:551
#24 0x00007f8b6db2f8b8 in rttest_spin_period (user_function=0x4211f5 <pendulum_control::RttExecutor::loop_callback(void*)>, args=0x1f12860, update_period=0xf35a50, iterations=0)
    at ../ws_ros2/src/ros2/realtime_support/rttest/src/rttest.cpp:608
#25 0x00007f8b6db2f4e9 in Rttest::spin (this=0xf35a48, user_function=0x4211f5 <pendulum_control::RttExecutor::loop_callback(void*)>, args=0x1f12860)
    at ../ws_ros2/src/ros2/realtime_support/rttest/src/rttest.cpp:539
#26 0x00007f8b6db2f3f3 in rttest_spin (user_function=0x4211f5 <pendulum_control::RttExecutor::loop_callback(void*)>, args=0x1f12860) at ../ws_ros2/src/ros2/realtime_support/rttest/src/rttest.cpp:512
#27 0x00000000004211bb in pendulum_control::RttExecutor::spin (this=0x1f12860) at ../ws_ros2/src/ros2/demos/pendulum_control/include/pendulum_control/rtt_executor.hpp:95
#28 0x0000000000415d20 in main (argc=3, argv=0x7ffc2fe66c68) at ../ws_ros2/src/ros2/demos/pendulum_control/src/pendulum_demo.cpp:291

The relevant pieces of information are in the following frames:

(15) While checking for the existence of a symbol which locks a mutex
(12) the incoming SIGINT signal is being handled
(7) which in order to trigger the guard condition needs to check the existence of a different symbol
🔒

If the used mutex would be recursive that wouldn't be a problem. But until Poco 1.4.1p1 Poco uses a non-recursive mutex on Linux. Since Xenial is using version 1.3.6p1 we see the deadlock.

Possible workarounds:

Use a newer version of Poco (newer Ubuntu distro have a new enough version).
Build using a single rmw implementation which avoids the usage of Poco in the rmw_implemenation package.

New failing test: test_tutorial_set_and_get_parameters__rmw_fastrtps_cpp

Starting with build: http://ci.ros2.org/view/nightly/job/nightly_linux_repeated/696, the test known as test_tutorial_set_and_get_parameters__rmw_fastrtps_cpp started failing. If you search for 'test_tutorial_set_and_get_parameters__rmw_fastrtps_cpp' in the console output, you'll see that this test started timing out.

use of Context in intra process demos

Suppose I modify the two node pipeline such that there are now four nodes but one pair have a common context and the others don't. Then by the defination of using context the two pairs will not share their messages.
auto producer = std::make_shared<Producer>("producer","number");
auto consumer = std::make_shared<Consumer>("consumer", "number");
auto context_test = std::make_shared<rclcpp::Context>();
auto producer2 = std::make_shared<Producer2>("producer2","number",context_test);
auto consumer2 = std::make_shared<Consumer2>("consumer2", "number",context_test);

However that is not the case when I am using the above definition in a modified two_nodes_pipeline source code, as both the pair of nodes are receiving each other messages.Is there something I am doing wrong ?

allocator_tutorial publishes a message every millisecond, which floods the network

Bug report

Required Info:

Operating System:
- Ubuntu Bionic arm64
Installation type:
- Fat archive from 2018-06-21, downloaded from here: https://ci.ros2.org/view/packaging/job/packaging_linux-aarch64/475/artifact/ws/ros2-package-linux-aarch64.tar.bz2
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- rclcpp

Steps to reproduce issue

As can be seen here, the allocator_tutorial publishes a message every millisecond. This ends up flooding the network, which is a problem over wireless. Is this test meant to stress the environment like this, or should we reduce this to publishing once every 10 or 100 milliseconds?

Compisition wiki page update

@dirk-thomas I'm planning on adding a section for dlopen_composition at the end of the composition tutorial page. Does this text sound reasonable to you ?

### Run-time composition using dlopen

This demo presents an alternative to 1. by creating a generic container process and pass it explicitely 
the libraries to load without using ROS interfaces. The process will open each library and create one 
instance of each "rclcpp::Node" class in the library [source code](https://github.com/ros2/demos/blob/master/composition/src/dlopen_composition.cpp)).

In the shell call:

        ros2 run composition dlopen_composition -- `ros2 pkg prefix composition`/lib/libtalker_component.so `ros2 pkg prefix composition`/lib/liblistener_component.so

Now the shell should show repeated output for each sent and received message.

dummy_robot_bringup launch file fails when started with `launch`

launch path-to/dummy_robot_bringup.py results in:

TypeError: launch() takes 0 positional arguments but 2 were given

Image viewer node won't take user input if no images are published

Bug report

Required Info:

Operating System:
- Ubuntu Bionic 18.04 (as in Nvidia OpenGL Docker image)
Installation type:
- Binary (debs)
Version or commit hash:
- Crystal pre-release.
DDS implementation:
- ADLink OpenSplice 6.9
Client library (if applicable):
- N/A

Steps to reproduce issue

Run the interprocess viewer step of the intra-process communication tutorial. Then drop the pipeline node and try to provide user input to the remaining image_viewer_node instance.

Expected behavior

image_viewer_node takes user input as documented.

Actual behavior

image_viewer_node ignores any user input and has to be terminated with a SIGINT.

Additional information

This is due to the way the node was implemented (see here).

[demo_nodes_py] talker_qos and talker don't use the same topic name

We can either merge them into a single executable or make them use the same topic (same for listener)

r2b3 ros2param crashes with `list /`

From @sloretz on September 13, 2017 0:48

Bug report

Required Info:

Operating System:
- Windows 10,
Installation type:
- http://ci.ros2.org/view/packaging/job/packaging_windows/728/artifact/ws/ros2-package-windows-AMD64.zip
Version or commit hash:
- def304b4270b6b935b7d6fbbf7671634c2532452
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- N/A

Steps to reproduce issue

ros2 run demo_nodes_cpp ros2param -- list /

Expected behavior

Not sure.

Actual behavior

ros2param.exe has stopped working

Additional information

Not from source, so unable to get a meaningful stack trace.

Copied from original issue: ros2/ros2cli#51

unsigned cast for listener_serialized_message.cpp

Bug report

Required Info:

Operating System:
- Ubuntu 16.04
Installation type:
- From source (but should not matter)
Version or commit hash:
- bc1fbed
DDS implementation:
- proprietary
Client library (if applicable):
- rclcpp

Steps to reproduce issue

Have binary char data with leading 1 (not 0)
-> Interpreted as negative number
-> Print fails

Expected behavior

Print data correctly aligned

Actual behavior

Print failed

Additional information

To fix this issue add a unsigned cast to:

demos/demo_nodes_cpp/src/topics/listener_serialized_message.cpp:55

cam2image crashes when specifying -x -y and -b

Bug report

Required Info:

Operating System:
- Windows 10
Installation type:
- binaries
Version or commit hash:
- https://ci.ros2.org/view/packaging/job/packaging_windows/1042/
DDS implementation:
- Fast-RTPS
Client library (if applicable):
- N/A

Steps to reproduce issue

ros2 run image_tools cam2image -b -x 16 -y 16

Expected behavior

Either a smaller image would be published or a message would be printed saying resizing the generated image is not supported.

Actual behavior

>ros2 run image_tools cam2image -b -x 16 -y 16
[INFO] [cam2image]: Publishing data on topic 'image'
OpenCV(3.4.1) Error: Assertion failed (0 <= roi.x && 0 <= roi.width && roi.x + roi.width <= m.cols && 0 <= roi.y && 0 <= roi.height && roi.y + roi.height <= m.rows) in cv::Mat::Mat, file C:\Users\osrf\opencv3-build\opencv\modules\core\src\matrix.cpp, line 464