If message contains either uninitialized string, an empty string, or string containing only a null terminating character, then rclpy publisher crashes:

>>> rclpy._rclpy.rclpy_publish(self.publisher_handle, msg)
RuntimeError: Failed to publish: error not set

modify typesupport import logic to allow message import before chosing rclpy implementation

You can reproduce this sometimes with a simple Python script like this one:

#!/usr/bin/env python3

import sys

import rclpy
from rclpy.qos import qos_profile_default

from sensor_msgs.msg import Imu


def main():
    rclpy.init(args=sys.argv)

    node = rclpy.create_node('imu_publisher')

    imu_publisher = node.create_publisher(Imu, 'imu_data', qos_profile=qos_profile_default)

    imu_msg = Imu()

    while True:
        # busy publish
        imu_publisher.publish(imu_msg)


if __name__ == '__main__':
    sys.exit(main())

Since this code spends most of the time in the .publish() function, which is mostly implemented inside a C python extension, you can sometimes get a segfault when doing ctrl-C rather than the expected KeyboardInterrupt. Note that I'm not using spin here.

For example, I get this from a similarly structured script:

william@ubuntu ~/ros2_ws 
% python3 emulate_kobuki_node.py
^C[1]    26835 segmentation fault (core dumped)  python3 emulate_kobuki_node.py

william@ubuntu ~/ros2_ws 
% python3 emulate_kobuki_node.py
^C[1]    26859 segmentation fault (core dumped)  python3 emulate_kobuki_node.py

william@ubuntu ~/ros2_ws 
% python3 emulate_kobuki_node.py
^C[1]    26883 segmentation fault (core dumped)  python3 emulate_kobuki_node.py

william@ubuntu ~/ros2_ws 
% python3 emulate_kobuki_node.py
^CTraceback (most recent call last):
  File "emulate_kobuki_node.py", line 39, in <module>
    sys.exit(main())
  File "emulate_kobuki_node.py", line 29, in main
    odom_publisher.publish(odom_msg)
  File "/home/william/ros2_ws/install_isolated/rclpy/lib/python3.5/site-packages/rclpy/publisher.py", line 27, in publish
    _rclpy.rclpy_publish(self.publisher_handle, msg)
  File "/home/william/ros2_ws/install_isolated/rclpy/lib/python3.5/site-packages/rclpy/impl/object_proxy.py", line 32, in __getattribute__
    def __getattribute__(self, attr):
KeyboardInterrupt

Undo #10.

Instead we should:

• Improve the error message when a Python extension doesn't exist for an otherwise valid rmw implementation
• Consider having a separate list of rmw implementations which provide a working Python extension
• Figure out how to de-duplicate the "default rmw implementation" logic that also exists in CMake: https://github.com/ros2/rmw/blob/739190b/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake#L35

Feature request

Feature description

Currently rclpy creates PyCapsule with NULL names. This means if a function is given a PyCapsule containing rcl_client_t * but it expects rcl_node_t * the C code will still attempt to use it as such. If the capsules were given a name at creation then the methods could use the name as a type check when getting the pointer.

Implementation considerations

https://docs.python.org/3/c-api/capsule.html
PyCapsule_New accepts a const char *name argument. It could be given a string like "rcl_node_t *".

// rcl_node_t * node;
PyObject * pynode = PyCapsule_New(node, "rcl_node_t *");

PyCapsule_GetPointer accepts a const char *name argument, and it sets a python exception and returns NULL if the name does not match (it uses strcmp() ).

rcl_node_t * node = (rcl_node_t *)PyCapsule_GetPointer(pynode, "rcl_node_t *");
if (!node)
{
  // GetPointer already set an exception
  return NULL;
}

If the default exception isn't appropriate, PyCapsule_GetPointer is guaranteed to succeed if PyCapsule_IsValid returns true. This can be checked first with custom handling code to run if it returns False.

// PyObject * pynode;
if (!PyCapsule_IsValid(pynode, "rcl_node_t *"))
{
  // Do something about it
}

This is a regression of #82, see this for more details:

#82 (comment)

It hangs when run against either server.

This example is fastrtps but I see the same issue for Connext.

Async_client doesn't quite finish when running against the python server

Bug report

Required Info:

• Operating System:
  • Ubuntu 16.04
• Installation type:
  • source
• Version or commit hash:
  • 98ad24a
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • rclpy

Steps to reproduce issue

import threading
import time

import rclpy
from rclpy.executors import SingleThreadedExecutor


if __name__ == '__main__':
    print('initializing rclpy')
    rclpy.init()
    node = rclpy.create_node('NodeName', namespace='/rclpy')

    print('Start executor in a new thread')
    executor = SingleThreadedExecutor()
    executor.add_node(node)
    exec_thread = threading.Thread(target=executor.spin)
    exec_thread.start()
    print('Sleep to make sure executor is blocked in rclpy_wait()')
    time.sleep(1)

    print('Shutdown executor and library')
    executor.shutdown()
    node.destroy_node()
    rclpy.shutdown()

    print('Thread cannot be joined because executor.spin() never returns')
    exec_thread.join()
    print('If this prints the issue is fixed')

Expected behavior

The thread in which spin is called should be joinable. executor.spin() should return when the executor is shutdown because there's no more work for it to do.

Actual behavior

The thread never becomes joinable.

Bug report

Required Info:

• Operating System:
  • Ubuntu 16.04 AMD64
• Installation type:
  • Source
• Version or commit hash:
  • Release versions of crystal, from ros2/ros2#624
• DDS implementation:
  • RTI Connext
• Client library (if applicable):
  • rclpy-ish

Steps to reproduce issue

Terminal 1:

ros2 launch topic_monitor depth_demo.launch.py

Terminal 2:

ros2 run topic_monitor topic_monitor
(hit Ctrl-C here)

Expected behavior

Topic monitor quits cleanly.

Actual behavior

Topic monitor quits with various different behaviors. One particularly nasty one:

[INFO] [topic_monitor]: /topic1_data: 159
[INFO] [topic_monitor]: /topic1_data: 160
[INFO] [topic_monitor]: /topic1_data: 161
[INFO] [topic_monitor]: /topic1_data: 162
[INFO] [topic_monitor]: /topic1_data: 163
[INFO] [topic_monitor]: /topic1_data: 164
[INFO] [topic_monitor]: /topic1_data: 165
[INFO] [topic_monitor]: /topic1_data: 166
[INFO] [topic_monitor]: /topic1_data: 167
[INFO] [topic_monitor]: /topic1_data: 168
[INFO] [topic_monitor]: /topic1_data: 169
^CRuntimeError: Failed to trigger guard_condition: guard condition handle implementation '�[�'(0x7f553e777db0) does not match rmw implementation 'rmw_connext_cpp'(0x7f553bf7c1a0), at /home/ubuntu/ros2_ws/src/ros2/rmw_connext/rmw_connext_shared_cpp/src/trigger_guard_condition.cpp:35, at /home/ubuntu/ros2_ws/src/ros2/rcl/rcl/src/rcl/guard_condition.c:160

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/ubuntu/ros2_ws/build/topic_monitor/topic_monitor/scripts/topic_monitor.py", line 420, in main
while data_receiving_thread.isAlive():
SystemError: PyEval_EvalFrameEx returned a result with an error set

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/ubuntu/ros2_ws/install/topic_monitor/lib/topic_monitor/topic_monitor", line 11, in <module>
load_entry_point('topic-monitor', 'console_scripts', 'topic_monitor')()
File "/home/ubuntu/ros2_ws/build/topic_monitor/topic_monitor/scripts/topic_monitor.py", line 420, in main
while data_receiving_thread.isAlive():
KeyboardInterrupt
[INFO] [topic_monitor]: /topic1_data: 170
[INFO] [topic_monitor]: /topic1_data: 171
[INFO] [topic_monitor]: /topic1_data: 172
[INFO] [topic_monitor]: /topic1_data: 173
[INFO] [topic_monitor]: /topic1_data: -1

And then it hung.

Additional information

It fails almost every time, with different behaviors.

Before rcl_wait is called, an existing signal handler is stored so that it can be called from within rclpy's signal handler. The existing signal handler is restored after waking up.

This is not currently robust to rclpy_wait being called from multiple threads; each thread ought to store its own signal handler to restore.

Is there an equivalent for rospy.Time.now() with rclpy? I know I can use the time function and build my own Time message for the standard Header messages. I want to know if this has already been implemented?

E.g. when the talker in the demo_nodes_py package is modified to contain a syntax error in the timer callback that is not being reported anywhere.

I am currently trying to make ros2 work on a new raspberry pi zero w using arch Linux and a cross compiler. After fixing multiple errors and bugs, there is only one problem left. Trying to run ros2 gives the following error:

Failed to load entry point 'launch': No module named 'rclpy._rclpy'
Failed to load entry point 'echo': No module named 'rclpy._rclpy'
usage: ros2 [-h] Call ros2 <command> -h for more detailed usage. ...

We have been recording our process here if anyone wants to try and reproduce the error: https://github.com/austinstig/ros2-raspberry-pi-zero-w

Any help would be greatly appreciated.

Thanks!

Feature request

Feature description

Meta ticket to track improvements we want to make to services and service-related features. This is not an exhaustive list, feel free to complete it

• create a "graph_listener" equivalent to use for wait_for_service (related to #58)
• refactor client to store pending requests
• refactor clients to return a future for each request sent and provide an equivalent of rclcpp::spin_until_future_complete() at the executor level

connects to #170

To settle on before tagging the release.

Since #147, all classes inheriting from rclpy.Node need to explicitly import rclpy.node.Node (see ros2/demos#196).

It would be great to allow users to use that class without having to explicitly import it as it was the case before.

@dirk-thomas could you provide more information about the need of delaying importing the singleton and the possible alternatives to restore previous usability?

It seems that the qos settings are not available in rclpy: https://github.com/ros2/rclpy/blob/master/rclpy/src/rclpy/_rclpy.c#L63. Is this true? When might such a feature be included?

meta-ticket.

First question: which usage do we want with respect to the severity:

1. loginfo(...) (like in ROS 1)
2. log(..., severity=INFO)

Second question: when considering the other logging variations, which do we want?

1. log_info_throttle_named(...) (like the C usage)
2. log_info(..., throttle_duration=1.0, name='my_name') (more pythonic IMO)

Feature request

Feature description

rclpy should provide a method to indicate if rclpy.init() has been called since the program started or since the last time rclpy.shutdown() was called.

Implementation considerations

This could also be served by provided a specific exception to raise when called too many times, currently it raises a generic RuntimeError, but I think a func to tell without raising an exception would also be good to have.

Should work after calling rclpy.shutdown() after originally calling rclpy.init() the first time.

[edit @dhood] connect to ros2/rclcpp#397

I noticed that the implement of rcl_take_response in rcl returns RCL_RET_ERROR and RCL_RET_CLIENT_TAKE_FAILED when the execution failed. So when this circumstance occurs, we should reset the error message to avoid being overwritten later. I have submitted a pr #141, PTAL thanks!

If the timeout in spin_once is set to zero (see snippet below) the program will continuously allocate new memory. If any other value or the default infinite timeout is chosen, everything works fine.

rclpy.init(args)
node = rclpy.create_node('test_node')
while rclpy.ok():
    rclpy.spin_once(node, 0)

Bug report

Required Info:

• Operating System:
  • Windows 10 (Fresh install on a VM)
• Installation type:
  • from archive 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

Symptom is a lot of errors when using ros2 command. This is after call C:\dev\ros2\local_setup.bat

C:\Users\osrf>ros2 --help
Failed to load entry point 'start': DLL load failed: The specified module could not be found.
Failed to load entry point 'status': DLL load failed: The specified module could not be found.
Failed to load entry point 'stop': DLL load failed: The specified module could not be found.
Failed to load entry point 'list': DLL load failed: The specified module could not be found.
Failed to load entry point 'call': DLL load failed: The specified module could not be found.
Failed to load entry point 'list': DLL load failed: The specified module could not be found.
Failed to load entry point 'echo': DLL load failed: The specified module could not be found.
Failed to load entry point 'list': DLL load failed: The specified module could not be found.
Failed to load entry point 'pub': DLL load failed: The specified module could not be found.
usage: ros2 [-h] Call `ros2 <command> -h` for more detailed usage. ...

ros2 is an extensible command-line tool for ROS 2.

optional arguments:
  -h, --help            show this help message and exit

Commands:
  daemon    Various daemon related sub-commands
  msg       Various msg related sub-commands
  node      Various node related sub-commands
  pkg       Various package related sub-commands
  run       Run a package specific executable
  security  Various security related sub-commands
  service   Various service related sub-commands
  srv       Various srv related sub-commands
  topic     Various topic related sub-commands

  Call `ros2 <command> -h` for more detailed usage.

Trying to load one of the entry points shows a traceback when importing _rclpy

>>> from ros2cli.verb.daemon import start
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\dev\ros2\Lib\site-packages\ros2cli\verb\daemon\start.py", line 15, in <module>
    from ros2cli.node.daemon import is_daemon_running
  File "C:\dev\ros2\Lib\site-packages\ros2cli\node\daemon.py", line 22, in <module>
    import rclpy
  File "C:\dev\ros2\Lib\site-packages\rclpy\__init__.py", line 17, in <module>
    from rclpy.executors import SingleThreadedExecutor as _SingleThreadedExecutor
  File "C:\dev\ros2\Lib\site-packages\rclpy\executors.py", line 21, in <module>
    from rclpy.impl.implementation_singleton import rclpy_implementation as _rclpy
  File "C:\dev\ros2\Lib\site-packages\rclpy\impl\implementation_singleton.py", line 32, in <module>
    rclpy_implementation = importlib.import_module('._rclpy', package='rclpy')
  File "C:\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ImportError: DLL load failed: The specified module could not be found.

Trying to import rclpy shows a similar error

>>> import rclpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\dev\ros2\Lib\site-packages\rclpy\__init__.py", line 17, in <module>
    from rclpy.executors import SingleThreadedExecutor as _SingleThreadedExecutor
  File "C:\dev\ros2\Lib\site-packages\rclpy\executors.py", line 21, in <module>
    from rclpy.impl.implementation_singleton import rclpy_implementation as _rclpy
  File "C:\dev\ros2\Lib\site-packages\rclpy\impl\implementation_singleton.py", line 32, in <module>
    rclpy_implementation = importlib.import_module('._rclpy', package='rclpy')
  File "C:\Python36\lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
ImportError: DLL load failed: The specified module could not be found.

Expected behavior

I'd expect no ImportError to be raised.

Actual behavior

Import error is raised

Additional information

sys.path

>>> import sys
>>> sys.path
['', 'C:\\dev\\ros2\\Lib\\site-packages', 'C:\\Python36\\python36.zip', 'C:\\Python36\\DLLs', 'C:\\Python36\\lib', 'C:\\Python36', 'C:\\Python36\\lib\\site-packages']

Not sure if I should see _rclpy.dll or something like that, but I don't. There is _rclpy.pyd, is that what is failing to be found?

C:\Users\osrf>dir C:\dev\ros2\Lib\site-packages\rclpy
 Volume in drive C has no label.
 Volume Serial Number is AA39-7FB6

 Directory of C:\dev\ros2\Lib\site-packages\rclpy

09/12/2017  09:38 AM    <DIR>          .
09/12/2017  09:38 AM    <DIR>          ..
09/12/2017  09:38 AM             3,527 callback_groups.py
09/12/2017  09:38 AM             3,126 client.py
09/12/2017  09:38 AM               646 constants.py
09/12/2017  09:38 AM             2,558 exceptions.py
09/12/2017  09:38 AM            16,545 executors.py
09/12/2017  09:38 AM             1,505 expand_topic_name.py
09/12/2017  09:38 AM    <DIR>          impl
09/12/2017  09:38 AM             2,535 logging.py
09/12/2017  09:38 AM            12,211 node.py
09/12/2017  09:38 AM             1,087 publisher.py
09/12/2017  09:38 AM             5,581 qos.py
09/12/2017  09:38 AM             1,449 service.py
09/12/2017  09:38 AM             1,270 subscription.py
09/12/2017  09:38 AM             2,157 timer.py
09/12/2017  09:38 AM             1,210 topic_or_service_is_hidden.py
09/12/2017  09:38 AM             1,203 utilities.py
09/12/2017  09:38 AM             1,709 validate_full_topic_name.py
09/12/2017  09:38 AM             1,568 validate_namespace.py
09/12/2017  09:38 AM             1,378 validate_node_name.py
09/12/2017  09:38 AM             1,710 validate_topic_name.py
09/12/2017  09:38 AM             1,716 _rclpy.lib
09/12/2017  09:38 AM            44,032 _rclpy.pyd
09/12/2017  09:38 AM             1,932 _rclpy_logging.lib
09/12/2017  09:38 AM            11,264 _rclpy_logging.pyd
09/12/2017  09:38 AM             1,654 __init__.py
09/12/2017  09:46 AM    <DIR>          __pycache__
              24 File(s)        123,573 bytes
               4 Dir(s)   6,535,761,920 bytes free

Follow up of #197.

When PyLong_FromUnsignedLongLong return NULL it should be reported somehow. If NULL is returned it needs to be ensured that it is handled correctly by all callers. Also the return value of PyList_Append should be checked.

When an executor spins it builds a wait list containing every entity (clients, services, publishers, etc) from the nodes added to it. If a new entity is created while the executor is spinning then it won't get added to the wait list until the executor executes unrelated work.

Creating a subscriber, client, etc should wake the executor.

For now every failure in rclpy raises a RuntimeError, we should create custom errors for different failure scenarios and avoid the tests of just catching random RuntimeErrors.

Feature request

rclpy seems to missing ROS Exceptions from rospy

Feature description

rospy has the following exceptions:

1. ROSInterruptException/ROSException - used in joint_state_publisher
2. ROSInitException - used in joint_state_publisher
3. ROSTimeMovedBackwardsException
4. ROSInternalException
5. TransportException/TransportTerminated/TransportInitError

rclpy seems to missing all the above exceptions. The following are more relevant to the migration

1. ROSInterruptException/ROSException - used in joint_state_publisher
2. ROSInitException - used in joint_state_publisher

Additionally, it might be useful to have ROSTimeMovedBackwardsException, I am not sure about 4 and 5

https://github.com/ros/ros_comm/blob/60be2504d5341eb3bc80d86e5d16f1c53dc97ccd/clients/rospy/src/rospy/exceptions.py

Implementation considerations

1. There is existing exceptions.py which could be extended to encase the missing exception
2. Create rosexception.py which entails all these exceptions

There is support for Clocks that use ROS Time as described in this design document. It was added in this PR.

Clocks can be set to have ROS time "active" (will use the value seen on the /clock topic as its time) by calling time_source.ros_time_is_active = True.

A node has a time source associated with it (added in #210). At the time of that PR, parameters were not available in rclpy, so the node's time source does not respond to the use_sim_time parameter:

As of #214, parameters are available in rclpy.

Tasks to get rclpy nodes to respond to the use_sim_time parameter:

• Add a parameter callback that detects if use_sim_time has been set on the node.
• Add tests that the node's clock output matches what's expected based on the combination of use_sim_time parameter and the presence of a /clock publisher. These are the tests in rclcpp.

If rclpy is imported globally, subprocesses don't seem to be able to access the underlying extensions.

Bug report

Required Info:

• Operating System:
  • Ubuntu 16.04
• Installation type:
  • from source
• Version or commit hash:
  • f776f597d7d5b325ab5d49486115b5267565937e2
• DDS implementation:
• Client library (if applicable):

Steps to reproduce issue

from example_interfaces.srv import AddTwoInts

import rclpy


def main(args=None):
    rclpy.init(args=args)
    node = rclpy.create_node('minimal_client')
    cli = node.create_client(AddTwoInts, 'add_two_ints')

    req = AddTwoInts.Request()
    req.a = 41
    req.b = 1
    while not cli.wait_for_service(timeout_sec=1.0):
        node.get_logger().info('service not available, waiting again...')

    cli.call(req)

    node.get_logger().info(
        'Result of add_two_ints: for %d + %d = %d' %
        (req.a, req.b, cli.response.sum))

    node.destroy_node()
    rclpy.shutdown()


if __name__ == '__main__':
    main()

Expected behavior

The client will receive the response from service side.

Actual behavior

The thread gets blocked after the line cli.call(req)

Additional information

suspicious commit 0c2ee4c

and remove all sleep calls made to compensate (e.g. https://github.com/ros2/examples/pull/140/files/247edc9b17cdcfc46ee7de8d9275b240c29d4156#diff-3915e3a2b8f90923e42c5386534ed581R32)

• Nodes contains parameters #214
• Nodes providing ROS services to interact with the parameters #214
• Parameters can be passed through CLI #225
• Parameter events are published on updates. #226
• Nodes can have a parameters_callback set which can arbitrarily accept and reject setting parameters. #228
• System tests for rclpy which exercise the parameters API, events, and services ros2/system_tests#293

Bug report

Required Info:

• Operating System:
  • macOS
• Installation type:
  • bouncy patch 2 rc
• DDS implementation:
  • Fast-RTPS
• Client library (if applicable):
  • rclpy

Steps to reproduce issue

% ros2 run demo_nodes_cpp listener &
% ros2 run demo_nodes_cpp listener &
% ros2 param set listener foo.bar.baz True
...
% ros2 param list
...

Expected behavior

Some times the last command will return:

% ros2 param list
listener:
  foo.bar.baz

Actual behavior

Some times the last command will return:

% ros2 param list
Traceback (most recent call last):
  File "/tmp/ros2-osx/bin/ros2", line 11, in <module>
    load_entry_point('ros2cli==0.5.4', 'console_scripts', 'ros2')()
  File "/tmp/ros2-osx/lib/python3.7/site-packages/ros2cli/cli.py", line 69, in main
    rc = extension.main(parser=parser, args=args)
  File "/tmp/ros2-osx/lib/python3.7/site-packages/ros2param/command/param.py", line 40, in main
    return extension.main(args=args)
  File "/tmp/ros2-osx/lib/python3.7/site-packages/ros2param/verb/list.py", line 81, in main
    rclpy.spin_until_future_complete(node, futures[node_name])
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/__init__.py", line 126, in spin_until_future_complete
    executor.spin_until_future_complete(future)
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/executors.py", line 218, in spin_until_future_complete
    self.spin_once()
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/executors.py", line 528, in spin_once
    raise handler.exception()
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/task.py", line 206, in __call__
    self._handler.send(None)
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/executors.py", line 308, in handler
    await call_coroutine(entity, arg)
  File "/tmp/ros2-osx/lib/python3.7/site-packages/rclpy/executors.py", line 253, in _execute_client
    future = client._pending_requests[sequence]
KeyError: 1

Additional information

I think this is a violation of the assumption that nodes have unique names (violated by running listener twice without renaming at least one of them), but this error in the executor could probably be made more robust and/or informative.

Separately, this underscores the need to resolve the node name uniqueness issue, see: ros2/design#187

Based on the discussion in #199 it needs to be ensured that exceptions are visible.

This ticket is to track rclpy specific time impelementation requirements

• implement a Clock on top of rcl implementation: #209
• implement a TimeSource to implement the ROS2 time design: #210
  • use parameters for use_sim_time when now that parameters are available in rclpy. #240
  • clock jump callbacks: #222
• upgrade Timer to use a Clock on top of rcl implementation
  • functionality using rcl clocks: #211
  • let users specify the clock to use: update this TODO #419
• Implement a Rate method using the clock on top of rcl implementation (#443)

While testing some things for a discourse question (https://discourse.ros.org/t/how-to-shutdown-and-reinitialize-a-publisher-node-in-ros-2/4090/3?u=wjwwood), I created this script:

import sys

import rclpy
from rclpy.node import Node

from std_msgs.msg import String


def main():
    msg = String()
    i = 0

    while True:
        rclpy.init()

        node = Node('talker')
        pub = node.create_publisher(String, 'chatter')
        msg.data = 'Hello World: {0}'.format(i)
        i += 1
        node.get_logger().info('Publishing: "{0}"'.format(msg.data))
        pub.publish(msg)

        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

Which works fine, but one time when I did ctrl-c on it I got a segmentation fault:

...
[INFO] [talker]: Publishing: "Hello World: 336"
[INFO] [talker]: Publishing: "Hello World: 337"
^CTraceback (most recent call last):
  File "/tmp/testing/talker.py", line 31, in <module>
    main()
  File "/tmp/testing/talker.py", line 26, in main
    node.destroy_node()
  File "/Users/william/ros2_ws/install_release/lib/python3.6/site-packages/rclpy/node.py", line 286, in destroy_node
    _rclpy.rclpy_destroy_entity(self.handle)
KeyboardInterrupt
[1]    48020 segmentation fault  python3 /tmp/testing/talker.py

I've been trying to catch it in the debugger but I haven't been able to do so, and I don't really have time to track down the source right now, so I though I'd make an issue and see if anyone else had time or interest to track it down.

test_create_service has been giving errors sometimes on windows debug nightlies lately (first time Oct 28):

Fatal Python error: C:\J\workspace\nightly_win_deb\ws\src\ros2\rclpy\rclpy\src\rclpy\_rclpy.c:1444 object at 000001F7B40882C0 has negative ref count -7870023856155525121
ValueError: Failed to create service due to invalid topic name '/get/42parameters': topic name is invalid, at C:\J\workspace\nightly_win_deb\ws\src\ros2\rcl\rcl\src\rcl\expand_topic_name.c:67

Current thread 0x00000a38 (most recent call first):
  File "C:/J/workspace/nightly_win_deb/ws/src/ros2/rclpy/rclpy\rclpy\node.py", line 177 in create_service
  File "C:\J\workspace\nightly_win_deb\ws\src\ros2\rclpy\rclpy\test\test_node.py", line 75 in test_create_service

http://ci.ros2.org/job/nightly_win_deb/659/testReport/junit/(root)/projectroot/rclpytests/

It seems to be unhappy with this Py_DECREF upon service init failure that was added in #129:
https://github.com/ros2/rclpy/pull/129/files#diff-80dda03110b5be606b823d6b0558b5c2R1444

Looking closer it seems to just be accidentally referencing service instead of pyservice so I'll fix it up now (still opening this ticket for future reference and visibility).

If I set the environment variable RCLPY_IMPLEMENTATION to a valid rmw implementation name and then run tests for rclpy, the set_rmw_implementation tests fail with output like:

1: Traceback (most recent call last):
1:   File "/usr/lib/python3.4/multiprocessing/pool.py", line 119, in worker
1:     result = (True, func(*args, **kwds))
1:   File "/home/jackie/code/ros2_ws/src/ros2/rclpy/rclpy/test/test_select_rmw_implementation.py", line 24, in run_catch_report_raise
1:     return func(*args, **kwargs)
1:   File "/home/jackie/code/ros2_ws/src/ros2/rclpy/rclpy/test/test_select_rmw_implementation.py", line 46, in func_import_each_available_rmw_implementation
1:     rmw_implementation, set_rmw)
1: AssertionError: expected 'rmw_connext_dynamic_cpp' but got 'rmw_connext_cpp'
1: """
1: 
1: The above exception was the direct cause of the following exception:
1: 
1: Traceback (most recent call last):
1:   File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
1:     self.test(*self.arg)
1:   File "/home/jackie/code/ros2_ws/src/ros2/rclpy/rclpy/test/test_select_rmw_implementation.py", line 56, in test_import_each_available_rmw_implementation
1:     args=(func_import_each_available_rmw_implementation, rmw_implementation,)
1:   File "/usr/lib/python3.4/multiprocessing/pool.py", line 253, in apply
1:     return self.apply_async(func, args, kwds).get()
1:   File "/usr/lib/python3.4/multiprocessing/pool.py", line 599, in get
1:     raise self._value
1: AssertionError: expected 'rmw_connext_dynamic_cpp' but got 'rmw_connext_cpp'

The purposes of trying to was so that I could set a different rmw implementation for rclpytests to see if connext dynamic was working.

Perhaps the test should unset the variable before running. Additionally, the talker/listener test should be changed to iterate through the different rmw implementations.

Carried over from #11.

The logic exists in CMake: https://github.com/ros2/rmw/blob/739190be1ddfb7470652152148297704360287e3/rmw_implementation_cmake/cmake/get_default_rmw_implementation.cmake#L36

And here in Python: https://github.com/ros2/rclpy/blob/master/rclpy/rclpy/impl/rmw_implementation_tools.py#L89

Bug report

Required Info:

• Operating System:
  Ubuntu 16.04
• Installation type:
  Custom build including CoreDX, FastRTPS, and OpenSplice
• Version or commit hash:
  Beta3 (exactly)

Steps to reproduce issue

Start a python3 ROS2b3 node without libopensplice67 installed. Send it some data or have it send some.

Expected behavior

No problems with libopensplice67 absent -- just like the rclcpp nodes.

Actual behavior

You get this error and crash: ros2-linux/lib/libstd_msgs__rosidl_typesupport_opensplice_cpp.so: error: symbol lookup error: undefined symbol: _ZTIN3DDS10OpenSplice21TypeSupportMetaHolderE (fatal)

I've attached the full LD log.
ld_debug.txt.zip

This is a tracking ticket for checking return values in rclpy. These functions are used and can fail, but their return value is not being checked.

• PyList_New
• PyCapsule_New
• PyLong_FromUnsignedLongLong
• PyMem_Malloc
• PyUnicode_FromString
• PyLong_FromSize_t
• PyObject_GetAtterString
• PyLong_FromLongLong
• PyCapsule_GetName
• PyList_Append
• PyObject_CallObject
• PyTuple_New
• PyTuple_SetItem
• PyList_SetItem
• PyImport_ImportModule
• PyObject_SetAttrString

From discussion here
#138 (comment)
#138 (comment)

Labeling this as good first issue. This doesnt imply that a contribution for this should tackle all the functions listed above

listener_py is failing for me for all four RMW implementations on OS X, from source. It will fail if a talker_py is not running. Even if a talker is running, it will also eventually fail, though not always immediately.

Here's the error:

$ listener_py
RTI Data Distribution Service EVAL License issued to SE [email protected] For non-production use only.
Expires on 02-Nov-2016 See www.rti.com for more information.
I heard: [Hello World: 7]
Traceback (most recent call last):
  File "/Users/deanna/ros2_ws/install/bin/listener_py", line 9, in <module>
    load_entry_point('rclpy-examples', 'console_scripts', 'listener_py')()
  File "/Users/deanna/ros2_ws/build/rclpy_examples/listener_py.py", line 39, in main
    rclpy.spin_once(node)
  File "/Users/deanna/my_ros2_ws/install/lib/python3.5/site-packages/rclpy/__init__.py", line 72, in spin_once
    msg = _rclpy.rclpy_take(subscription.subscription_handle, subscription.msg_type)
RuntimeError: Failed to take from a subscription: error not set

Bug report

Required Info:

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

Steps to reproduce issue

Start add_two_ints_server.exe using either fastrtps or connext

set RMW_IMPLEMENTATION=rmw_fastrtps_cpp
C:\dev\ros2-windows\Lib\demo_nodes_py\add_two_ints_server.exe

set RMW_IMPLEMENTATION=rmw_connext_cpp
C:\dev\ros2-windows\Lib\demo_nodes_py\add_two_ints_server.exe

Try to interrupt the server using CTRL + c

Expected behavior

Processes would print a traceback ending in KeyboardInterrupt and exit

Actual behavior

No apparent response. Process does not print anything to console, and must be killed using the task manager.

Additional information

I see the expected behavior using rmw_opensplice_cpp

Feature request

Feature description

Something like the rospy.on_shutdown() handle.

Implementation considerations

Primary use case here is so that authors of scripts/applications do not need to remember a long sequence of magic shutdown calls. e.g.

try:
    rclpy.spin(node)
except KeyboardInterrupt:
     pass
foo.shutdown()
bar.shutdown()
node.destroy_node()
rclpy.shutdown()

Instead, the shutdown methods would register themselves in a setup phase inside the class and subsequently the author of the main script need not worry about the shutdown methods at all.

Bug report

Required Info:

• Operating System:
• Installation type:
• Version or commit hash:
• DDS implementation:
• Client library (if applicable):

Steps to reproduce issue

when using message_filters python package, 
I got AttributeError: 'Time' object has no attribute 'nanoseconds', this caused by my rclcpp version isn't match the message_filter version, 
so i tried latest-release branch, but it also doesn't have this  modul.
 At last, I tried the master branch which has "nanoseconds", but the compilation was not successful. 

Expected behavior

Actual behavior

Additional information

Feature request

Feature description

Implementation considerations

import rclpy
Traceback (most recent call last):
File "", line 1, in
File "/opt/ros/r2b3/lib/python3.5/site-packages/rclpy/init.py", line 26
def init(*, args=None):
^
SyntaxError: invalid syntax

system ubuntu 16.04

Requested by @stonier.

Bug report

Required Info:

• Operating System:
  Ubuntu 16.04
• Installation type:
  from source
• Version or commit hash:
  0.5.3 eb97379
• DDS implementation:
  opensplice
• Client library (if applicable):
  rclpy

Steps to reproduce issue

change the demo_node_py talker's publish frequency to 20Hz and start the talker with command 'python3 talker.py'
then press Ctrl-C to interrupt it. in some case, it may cause segmentation fault.

the traceback of gdb :

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python3 talker.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fb0ffd75049 in rmw_trigger_guard_condition (guard_condition_handle=0x7c001e7200096b00)
    at /home/tusimple/ros2_zoro/src/hpc-zoro/rmw_zoro_cpp/src/rmw_trigger_guard_condition.cpp:30
30	    if (guard_condition_handle->implementation_identifier != tusimple_zoro_identifier) {
[Current thread is 1 (Thread 0x7fb0fcc1d700 (LWP 28506))]
(gdb) bt
#0  0x00007fb0ffd75049 in rmw_trigger_guard_condition (guard_condition_handle=0x7c001e7200096b00)
    at /home/tusimple/ros2_zoro/src/hpc-zoro/rmw_zoro_cpp/src/rmw_trigger_guard_condition.cpp:30
#1  0x00007fb1011bec1a in rmw_trigger_guard_condition ()
   from /home/tusimple/ros2_bb/install/rmw_implementation/lib/librmw_implementation.so
#2  0x00007fb1013d0010 in rcl_trigger_guard_condition (guard_condition=0x29f9310)
    at /home/tusimple/ros2_bb/src/ros2/rcl/rcl/src/rcl/guard_condition.c:152
#3  0x00007fb101ca5ac6 in catch_function (signo=2) at /home/tusimple/ros2_bb/src/ros2/rclpy/rclpy/src/rclpy/_rclpy.c:47
#4  0x00007fb0fdbf6c7b in ?? () from /usr/lib/libddskernel.so
#5  0x00007fb0fdc34542 in ?? () from /usr/lib/libddskernel.so
#6  0x00007fb1031ee6ba in start_thread (arg=0x7fb0fcc1d700) at pthread_create.c:333
#7  0x00007fb102f2441d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Right now _rclpy.c is full of asserts. Would be great to throw or return accordingly. This is also related to #31

When I publish complicated message, the ros message could not be successfully destroyed, which will lead to memory leak!

When I define complicated message type, which includes variable-length array of submessage, the message could not be successfully destroyed.

You can reproduce it by the following three steps:
(1)Download the code here: https://github.com/gong0029/zoro_test
(2)Compile the three packages: newzoro_msgs, newzorotmp_msgs and pub_and_sub_py
(3)Run the command: ros2 run pub_and_sub_py talkerN1

You will see the memory is keep on increasing.

I think the reason is that:

The message (ZoroMsg) includes variable-length array of submessage (newzorotmp_msgs/TmpMsg[] mdata).
However, in the file "https://github.com/ros2/rclpy/blob/master/rclpy/src/rclpy/_rclpy.c ", Line 1159,
the function destroy_ros_message(raw_ros_message) could not fully free the field mdata.

This is a portion of work from #186. I propose the first step to be an implementation of Clock class, similar to what's done in rclcpp/clock.hpp and in rclcpp/clock.cpp without jumps.

I found WallTimer class in rclpy, but I could not figure out a relationship between clock and timer.

@tfoote - I am looking forward to your feedback.

The existing Time class must have a clock type. In use cases where you just want to represent a time (which could e.g. come from a message with a time field) that data structure isn't suitable since there isn't a specific clock associated to the time.

But on the other hand you want to be able to leverage the features available in the existing time class (like conversion to nanoseconds, operations, normalization of the seconds / nanoseconds.

Therefore I would propose to have a Time class which only contains the data. and a separate TimeWithClock (names just for illustration) which contains an instance of the Time class and a clock (which performs the checks for same clocks before applying the operators defined in the Time class).

--

An alternative would be to use the builtin_interfaces/Time message as the data type but that would require that this data structure can be enhanced with operators and accessors.