Persistent ALARM 8014 Invalid MotoROS2 job detected [1] #264
-
|
Upon initiating the microros Docker client, there will always be an alarm 8014 [1]. This has been preventing proper communication with the FollowJointTrajectory Action Server though published topics from the bot are still functional. I have attempted to clear this first by removing all job files .DAT/.JBI from the connected USB (to remove any invalid jobs) and then again by setting allow_custom_inform to true. In both cases, the Invalid MotoRos2 job is detected. At this point the controller is preventing new motoros2_config.yaml files to be loaded even with forced override. ROS_INIT.JBI file is not recreated despite controller restart attempts. Before deletion, I compared the ROS_INIT.JBI file to the examples in the repo and noted the only difference being the timer period being .5 seconds instead of .05. Controller is a YRC1000micro and the robot is the yaskawa HC10DT. MotoRos2 Installation has been verified through the md5sum procedure. Version is Humble 0.1.2. Debug log here: Click to expandConfig 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.1"
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: ""
#-----------------------------------------------------------------------------
# Namespace to use for the MotoROS2 node and all topics.
#
# DEFAULT: "" (empty string)
#node_namespace: ""
#-----------------------------------------------------------------------------
# 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: true
#-----------------------------------------------------------------------------
# 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 transformapplicationss on '/tf'? This can be disabled if
# the data will interfere with 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:
#- [group_1/joint_1, group_1/joint_2, group_1/joint_3, group_1/joint_4, group_1/joint_5, group_1/joint_6]
#-----------------------------------------------------------------------------
# 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: false
#-----------------------------------------------------------------------------
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: falseController Version Information: |
Beta Was this translation helpful? Give feedback.
Answered by
luke-reframe
Jun 19, 2024
Replies: 4 comments 5 replies
-
|
Hi @luke-reframe If that release doesn't resolve the issue, please reopen this issue and include the full debug output, including the top part where the configuration data is parsed. (You'll need to start the python logger before booting the YRC.) As a short-term fix, you can modify line 3 of the ROS_INIT job on the teach pendant.
Change the TIMER to |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I just noticed that you did say you're using 0.1.2. Please post the full output of the debug log and also the job which was generated. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi @ted-miller Here is the generated Job Click to expandHere is the full debug log Click to expandThank you |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
@ted-miller: I find it interesting the ie: Parsing issue? Edit: there is no parsing IIUC: motoros2/src/InformCheckerAndGenerator.c Lines 259 to 279 in d8b75dd |
Beta Was this translation helpful? Give feedback.
-
|
@luke-reframe, I believe there is a mismatch between the job on your controller and what is on your computer. As gavanderhoorn points out, the Please delete the INIT_ROS job from your YRCmicro and then reboot the controller. When MotoROS2 doesn't find the job at startup, it will recreate the job. Alternatively, you can modify the config yaml file to set |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I have been able to successfully clear the error and successfully send a FollowJointTrajectory Goal to the action server after editing the ROS_INIT job file on the pendant. It appears that both the timing was incorrect and a line had been commented out. Thank you for the assistance. |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Good to hear you got things to work. Could you confirm the job that had the incorrect lines was manually created? If this was auto-generated by MotoROS2, we should check what's going on. |
Beta Was this translation helpful? Give feedback.
-
|
I cannot necessarilly confirm that the job was autogenerated by MotoROS2 as several people have touched this robot. |
Beta Was this translation helpful? Give feedback.
-
|
It'd be interesting to see whether removing the job from the YRC1000u and restarting the controller results in the correct job being generated by MotoROS2. If that works, it's likely the job you had on there before was either manually created, or at least altered. |
Beta Was this translation helpful? Give feedback.
Answer selected by
gavanderhoorn
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I have been able to successfully clear the error and successfully send a FollowJointTrajectory Goal to the action server after editing the ROS_INIT job file on the pendant. It appears that both the timing was incorrect and a line had been commented out.
Thank you for the assistance.