Segmentation Fault when running MotoROS services
Aneeer opened this issue · 6 comments
Aneeer commented
Hi Ted + Team,
ROS Version: Rolling
MicroROS Image: Latest
MotoROS2 Version: 0.1.1
Uploaded yaml file as .txt since github doesn't support yaml uploads in issues
Moving my issue here from the email thread. Can currently see joint states from the robot but running any of the MotoROS2 services results in segmentation fault. The issue persists with echoing robot status.
motoros2_config.yaml:
Click to expand
---
# SPDX-FileCopyrightText: 2022-2023, Yaskawa America, Inc.
# SPDX-FileCopyrightText: 2022-2023, Delft University of Technology
#
# SPDX-License-Identifier: Apache-2.0
#-----------------------------------------------------------------------------
# REQUIRED
# IP address and UDP port number of the Micro-ROS Agent PC. All communication
# to/from MotoROS2 will route through the Agent application.
# (There is no default value for these fields. They must be specified by
# the user.)
agent_ip_address: "192.168.1.10"
agent_port_number: 8888
# Any settings that are not specified will be set to their DEFAULT value.
#-----------------------------------------------------------------------------
# The (DDS) domain to join
#
# Please refer to the ROS 2 documentation on DDS domain IDs for more
# information. This setting works exactly like its ROS 2 analogue.
#
#DEFAULT: 0 (the default ROS 2 domain ID)
ros_domain_id: 0
#-----------------------------------------------------------------------------
# Name under which MotoROS2 should register with the ROS 2 node graph.
#
# DEFAULT: "motoman_xx_yy_zz" (xyz: last three bytes of robot's MAC address)
node_name: "gp180_120"
#-----------------------------------------------------------------------------
# Namespace to use for the MotoROS2 node and all topics.
#
# DEFAULT: "" (empty string)
node_namespace: "gp180_120"
#-----------------------------------------------------------------------------
# Remap rules to apply to ROS 2 resource names.
#
# This configures the micro-ROS equivalent of the ROS 2 remap functionality.
#
# The current implementation expects all remap rules as a single,
# space-separated string. Whitespace in resource names is not allowed, so
# this should not pose any issues.
#
# Maximum total length of the remap_rules string: 255 chars. Any characters
# beyond that will be ignored (and likely result in parsing failures).
#
# Please refer to the ROS 2 documentation on remapping for more information
# on syntax and contraints.
#
# Example: the following remaps the 'joint_states' topic to 'my_joint_states',
# and the 'read_single_io' service to 'io/read_single':
#
# "joint_states:=my_joint_states read_single_io:=io/read_single"
#
# DEFAULT: "" (empty string)
remap_rules: ""
#-----------------------------------------------------------------------------
# This will ensure that when timestamps are sampled, they will match the clock
# of the Agent PC. This is useful if the date/time of the robot controller is
# not synchronized.
#
# DEFAULT: true
sync_timeclock_with_agent: false
#-----------------------------------------------------------------------------
# Should MotoROS2 monitor the link state of the ethernet port used to
# communicate with the Agent?
#
# If enabled, this will cause immediate notification of loss-of-connection
# when the link goes down, causing MotoROS2 to activate it's shutdown
# behaviour (ie: stop all motion (if enabled), release resources, wait for
# link up and attempt reconnection with the Agent).
#
# If this is disabled, Agent disconnection detection uses an application
# layer based timeout mechanism which takes longer to detect disconnects (but
# might be more robust against intermittent link-layer disconnects which do not
# cause network disconnections).
#
# DEFAULT: true
userlan_monitor_enabled: true
#-----------------------------------------------------------------------------
# Which port should MotoROS2 monitor, if 'userlan_monitor_enabled' is 'true'?
#
# If not specified, MotoROS2 will attempt to auto-detect the network port
# that is used to connect to the micro-ROS Agent. It will do this by
# comparing the 'agent_ip_address' setting against the IP addresses (and
# netmasks) of all available network interfaces.
#
# If the Agent can be reached directly over a particular interface, or via a
# configured default gateway on the same interface, the associated port will be
# monitored for link drops.
#
# To disable auto-detection, uncomment 'userlan_monitor_port' below and set
# it to the desired port.
#
# NOTE: this setting only applies to YRC1000 and YRC1000u controllers.
# DX200 and FS100 controllers only have a single ethernet port, and any
# value other than 1 will be ignored.
#
# NOTE 2: auto-detection is not perfect. It can't determine whether the Agent
# might be reachable using multiple hops. Nor can it determine whether
# any routers have been configured to forward particular types of
# traffic or firewalls exist between MotoROS2 and the micro-ROS Agent.
# For deployments with complex network configurations, disable
# auto-detection by configuring 'userlan_monitor_port' below.
#
# NOTE 3: the port specified here is NOT checked against 'agent_ip_address'.
# In other words: if 'agent_ip_address' is on 'USER_LAN1', but
# 'userlan_monitor_port' is set to 'USER_LAN2', MotoROS2 will detect
# link down events on 'USER_LAN2', whether or not that port is used
# to communicate with the Agent.
#
# OPTIONS: USER_LAN1, USER_LAN2
# DEFAULT: USER_LAN1
userlan_monitor_port: USER_LAN1
#-----------------------------------------------------------------------------
# If the Agent PC disconnects from the robot while it is in motion, should the
# robot come to a stop?
#
# DEFAULT: true
stop_motion_on_disconnect: true
#-----------------------------------------------------------------------------
# Should MotoROS2 broadcast transforms on '/tf'? This can be disabled if
# the data will interfere with applications such as robot_state_publisher.
#
# DEFAULT: true
publish_tf: true
#-----------------------------------------------------------------------------
# Should the 'tf' topic be namespaced if 'node_namespace' is configured with a
# non-empty string?
#
# Setting this to 'false' will make MotoROS2 broadcast transforms on the '/tf'
# global topic, which cannot be namespaced (due to being an absolute name).
# Otherwise, it will broadcast on 'tf', which can be namespaced.
#
# DEFAULT: true
namespace_tf: true
#-----------------------------------------------------------------------------
# Similar to the 'frame_prefix' parameter of the ROS 2 'robot_state_publisher'
# node. All published TF frames will be prefixed with this string.
#
# Example: with this parameter set to "left/", the "r1/tool0" frame would be
# published as "left/r1/tool0".
#
# NOTE: the prefix must include a separator (fi: '/') if one should be included
# in the final name of the TF frames. Such a separator is not added
# automatically.
#
# DEFAULT: "" (empty string)
tf_frame_prefix: ""
#-----------------------------------------------------------------------------
# Joints in this configuration file must be listed in the order of Robots,
# Base-axes, Station-axes.
#
# Example: R1+B1+R2+S1 system
#
# joint_names:
# - [r1_s_axis, r1_l_axis, r1_u_axis, r1_r_axis, r1_b_axis, r1_t_axis]
# - [r2_s_axis, r2_l_axis, r2_u_axis, r2_r_axis, r2_b_axis, r2_t_axis, r2_e_axis]
# - [b1_axis]
# - [s1_axis_1, s1_axis_2]
#
# When using a 7 axis robot arm with an elbow joint (E) in the middle of the
# arm, the elbow axis should be listed last (SLURBTE).
#
# DEFAULT: "group_x/joint_y"
joint_names:
- [joint_1_s, joint_2_l, joint_3_u, joint_4_r, joint_5_b, joint_6_t]
#-----------------------------------------------------------------------------
# Logging settings
logging:
# All log messages are broadcast on the network on port UDP 21789.
# Additionally, the messages can be printed to the standard output stream of
# the robot controller. This would be visible over a telnet connection, or by
# attaching a VGA debug monitor to the robot controller.
#
# NOTE: this WILL slow down the application.
#
# DEFAULT: false
log_to_stdout: true
#-----------------------------------------------------------------------------
update_periods:
# The delay between checks for incoming activity on the network. A lower
# number will result in quicker responsiveness to received messages.
# Additionally, it determines the rate at which the feedback_publisher timers
# are checked.
# This value should be <= to action_feedback_publisher_period as executor_sleep_period
# is the rate at which the action-feedback timer is checked. If the value for
# action_feedback_publisher_period is < executor_sleep_period, it will effectively
# be treated as having the same value executor_sleep_period at runtime.
#
# DEFAULT: 10 milliseconds
executor_sleep_period: 10
# The delay between each publish of feedback position and status information.
# A lower number will publish the feedback data more frequently.
# This value should be >= to executor_sleep_period and
# controller_status_monitor_period.
#
# DEFAULT: 20 milliseconds
action_feedback_publisher_period: 20
# The delay between each poll of the robot I/O and controller status data.
# This value should be <= to action_feedback_publisher_period.
#
# DEFAULT: 10 milliseconds
controller_status_monitor_period: 10
#-----------------------------------------------------------------------------
# QoS profile to use for various publishers MotoROS2 creates.
# The default values here are based on tests and inspection of the source code
# of typical consumers of messages on these topics.
#
# NOTE : RViz2 expects/requires 'tf' to use the 'default' profile (ie: reliable).
# NOTE2: MoveIt2 expects/requires 'joint_states' to use the 'default' profile.
publisher_qos:
# DEFAULT: sensor_data
robot_status: sensor_data
# DEFAULT: sensor_data
joint_states: sensor_data
# DEFAULT: default
tf: default
#-----------------------------------------------------------------------------
# Name of the INFORM job to be used (and monitored) by MotoROS2.
#
# Maximum length: 32 UTF-8 characters. 16 Japanese (Shift-JIS) characters.
#
# Set this to a custom value when using a custom INFORM job with a different
# name.
#
# NOTE: do NOT include the file extension here (ie: '.JBI'). Only the name
# of the job should be specified.
#
# DEFAULT: "INIT_ROS"
inform_job_name: "INIT_ROS"
#-----------------------------------------------------------------------------
# Allow custom INFORM job.
#
# If MotoROS2 detects that the specified INFORM job is not formatted properly
# then an alarm will be raised at startup.
# This flag indicates that the job is intentionally configured and will
# suppress the alarm.
#
# When this flag is set to 'true', then MotoROS2 will not validate whether the
# job is compatible. It is the responsibility of the user to make sure the
# custom job includes the required INFORM statements and in the expected order
# (refer to the provided INFORM job files for the general structure).
#
# DEFAULT: false
allow_custom_inform: falseted-miller commented
Hi @Aneeer
Can you please include the following to help diagnose the issue?
- Version of ROS2 (Humble, Foxy, etc)
- Version of microros docker image
- Version of MotoROS2
- Copy of MotoROS2 configuration yaml file
- Full output of the debug log client from bootup until the error occurs
gavanderhoorn commented
ROS Version: Rolling
we currently don't support Rolling. See also General Requirements:
The following general requirements must be met in order to be able to use MotoROS2 with a Yaskawa Motoman robot controller:
[..]
- ROS 2 version: Foxy, Galactic or Humble. ROS 2 Iron Irwini is not yet supported.
there's a good possibility some incompatibility was introduced either in FastDDS or the message definitions which can cause SEGFAULTs when (de)serialising the messages.
@Aneeer: please retry with a Humble ROS 2 install. If you can reproduce the SEGFAULT with ROS 2 Humble, we would have to diagnose the cause.
And if you could share one of the core dumps, I could try to analyse it to see what exactly crashed.
Aneeer commented
Having looked at logs I was able to diagnose and fix the problem. Seems to have nothing to do with your package, but rather build/permissions issues on my PC. After cleaning my workspace and rebuilding I was able to remedy most everything.
This issue seems to arise when the dependencies related to MotoROS2 interfaces are incorrectly sourced.
gavanderhoorn commented
I was able to remedy most everything.
most everything?
Could you clarify what still didn't work?
And please still note that officially, Rolling is not supported.
ROS 2 does not guarantee binary compatibility between different versions of ROS, and MotoROS2 is only built on-top of binaries for Foxy (EOL), Galactic (EOL) and Humble at the moment.
It's very much possible breaking changes will be introduced in Rolling that will make it incompatible with MotoROS2.
Edit: also note: there is nothing right now in ROS 2 Humble which will warn you about the types of incompatibilities I describe in my earlier comment(s). Even if you don't see SEGFAULTs or errors about messages, services or actions, data might silently get corrupted.
Only with ROS 2 Iron were certain protections integrated.
Aneeer commented
Sorry let me clarify :)
- Most everything is everything related to the issue I opened, it was a poor choice of words
- I have taken your advice and switched to Humble
Hence I closed the issue. Does that answer your question?
gavanderhoorn commented
Yes. Thank you.