yaskawa-global / motoros2 Goto Github PK

Even when servos are off, values reported in JointState::velocity can fluctuate (as in: 'randomly' change).

This could be due to noise in the values reported by M+ APIs, or a conversion error on our end.

The fluctuations are relatively minor (ie: small fractional changes). In general the reported values appear to be OK.

MotoROS2 currently only publishes a single RobotStatus message which is an aggregate of the status of the complete controller (ie: all groups).

It might be a nice enhancement for MotoROS2 to publish per-group status messages, as the aggregate might not provide sufficient information about individual motion groups.

While asynchronous motion currently isn't supported, it's still possible for motion groups to not be involved in trajectories. With per-group status messages, it would be possible to convey the fact certain groups are in fact not in_motion, while others are.

A similar rationale could be given for motion_possible and drives_powered (individual groups can be disconnected from the controller, which currently can not be communicated using the aggregate message).

Tasks:

• update VS project with Iron targets for all supported controllers
• update M+ libmicroros build infra with Iron support
  • depends on micro-ROS
  • status: micro-ROS/micro_ros_setup#648
  • updates: micro-ROS/micro_ros_setup#647
  • updates to micro_ros_setup: micro-ROS/micro_ros_setup@humble...iron (or maybe micro-ROS/micro_ros_setup@humble...release/iron
• update documentation:
  • General requirements
  • Extracting the files
  • Agent
  • Only fast-dds is supported

MotoROS2 currently exposes a FollowJointTrajectory action interface on the follow_joint_trajectory ns (docs).

It would perhaps be nice(r) to instead configure the action server to use the joint_trajectory_controller/follow_joint_trajectory namespace.

Even though MotoROS2 does not support ros2_control (faq), changing our FollowJointTrajectory action server to use that namespace would more closely follow the standard namespacing of the ros(2)_control controller of the same name (ie: JointTrajectoryController). This in turn would make it more recognisable for users, and additionally make it easier to configure applications/frameworks like MoveIt, as they tend to (implicitly) assume/expect certain setups and might provide users with templates.

There are multiple instances of the SUBCODE_FAIL_MP_NICDATA error code in different source files. Although they both essentially have the same meaning, it is impossible to know exactly which line of code raised the error. This makes troubleshooting more difficult.

We should go through and make sure that no error code is repeated anywhere in the code.

SUBCODE_FAIL_MP_NICDATA instances:

and

The current implementation silently ignores failure to call mpGetRobotCalibrationData(..):

MotoROS2 won't crash if the call fails, but it will result in TF transforms being incorrect, which will surprise users of multi-robot systems (especially if they have performed the robot-to-robot calibration).

A new failure code should be defined and reported on the pendant.

I believe this:

uses strncat(..) incorrectly.

According to CodeQL: Potentially unsafe call to strncat, the third argument to strncat(..) should be set to:

[..] the maximum number of characters to append and should be less than or equal to the remaining space in the destination buffer

the code linked quoted above sets it to MAX_JOB_LINE_LENGTH, which is the full length of the buffer:

Now that MotoROS2 is more akin to a real ROS 2 node, we might consider adding a GUI to it.

A UI could be used to both show status of uMotoROS (ie: executing a goal, of length N, expected time to completion, etc) as well as allow users to interact with it (cancel a goal forcibly, toggle some settings, etc).

It would also perhaps be a way to clearly communicate to users holding the TP that "this robot is being controlled externally, using MotoROS2" -- something which is invisible at the moment.

A GUI for the standard pendant would need to be done by Yaskawa personnel. But anyone with a Smart Pendant could implement an extension. Extensions are created using either Java or C#. (If using C#, please post here first. There are some updates which have not been merged upstream yet.)

Another potential option would be a simple I/F panel. It's not as pretty or customizable, but it can convey valuable information.

Implement a service (perhaps motoros2_interfaces/GetActiveAlarmInfo or similarly named) which clients could invoke to retrieve more information about active alarms/errors.

We could expose other data next to alarm subcode data. If available, we could perhaps have it return string descriptions of alarms & errors and other information (possible remedies?).

We can't add this to our RobotStatus publications, as that message doesn't have the necessary fields (and they can't be added either, as it should stay generic / vendor-neutral).

Edit: note that this service is not intended to be a replacement of RobotStatus. Retrieving the information returned by the service incurs overhead, and should really only be used to get more insight into alarms/errors reported via RobotStatus publications.

The current implementation only prints the <key, value> pairs of config items it parses.

That's helpful, but anything which is not present in the configuration .yaml -- and so should get its default set -- will not be printed.

As we might change defaults over time, it would be important to have a complete dump of the g_nodeConfigSettings struct after parsing has finished.

ROS applications do not currently have access to any information about the state of FSU power and/or velocity limits, nor can they tell when an FSU enforced limit has altered an executed trajectory (either in space, or in time).

This can lead to unexpected behaviour of the robot, as well as on the ROS side.

(MotoROS2 will do a final check at the last trajectory point to see whether position tolerances specified in the trajectory goal are met, and return an error if that's not the case. While better than nothing, this is insufficient and mostly for humans. It also does not offer any information as to a cause)

We should find a way to make FSU and/or PFL status visible to ROS applications (MoveIt fi), such that appropriate action can be taken by them (ie: replan instead of abort, or reduce maximum velocity and/or acceleration limits).

The frequency for publishing topics is configurable in the motoros2_config.yaml configuration file. Initial testing has revealed that the MotoROS2 is limited to about 100 Hz.

0.1.0 added features to attempt to improve the publish rates. While it did in fact improve things, there are still limits imposed by the QoS settings. Topics with a reliable quality seem to take ~10 ms to publish. Can this be improved upon?

MotoROS2 currently does not support replacing an already executing trajectory with another. All trajectories must start from a full stop and must end with one.

The joint_trajectory_controller of ros_control allows clients to submit a new goal while one is already executing. If enabled, it will attempt to smoothly blend the old trajectory with the new one:

Similar behaviour could be supported by MotoROS2.

Note that in addition to the FollowJointTrajectory action server which MotoROS1 also supports, MotoROS2 supports a point queuing mode, which allows to submit individual trajectory points, one after the other which essentially allows for an "infinite" trajectory to be executed.

Trajectory replacement however would use trajectories as the smallest unit, not points. If trajectories are submitted at appropriate times however, it would also allow for an "infinite" motion to be executed, with the robot never stopping between trajectories, only transitioning.

As per subject.

Help users report issues with sufficient information to make/keep them actionable.

Additionally, clarify when the Discussions board should be used instead of posting issues.

Context: ros-industrial/motoman#458 (comment).

We could consider making HTRAJON the default in all our INFORM jobs -- including the generated job -- but this changes the behaviour of MotoROS2 (motion commands will be executed differently) and it's unclear at this point whether the reduced latency / increased aggressiveness is an improvement in all cases.

Additional relevant comment by @ted-miller in ros-industrial/motoman#458 (reply in thread).

I'm commanding what should be a smooth continuous motion between two points. But, there is a slight (visible) hesitation between the points.

Happens on both streaming and FJT interfaces.

It's not always there, or at least it's not always noticeable, but I believe that's just because I'm a human, looking at a robot and not measuring stuff.

Possibilities:

• processing delay due to motoros2_fjt_pt_queue_proxy 'hammering' the point queue service server (I reduced the time between attempts to 0.05 sec)
• some emergent math behaviour in the code calculating the accelerations (and the velocities, etc)
• the code that actually processes the JointTrajectoryPoints (via the 'fake' single-point trajectories)

We don't have anything to back any of that up though right now.

The maximum TF frame prefix length is set to MAX_YAML_STRING_LEN here:

with MAX_YAML_STRING_LEN set to 128 here:

The total allowed TF frame name length is limited to MAX_TF_FRAME_NAME_LENGTH:

This is potentially problematic here:

as we concatenate the prefix with the non-prefixed frame name. Theoretically, a user could configure a prefix with length 100 (or something > 96) and we'd end up with all transforms having their frame_id and child_frame_id set to the frame_prefix.

The current implementation of Ros_ConfigFile_CheckUsbForNewConfigFile() copies and renames the new .yaml file it finds on CN102 without verifying it is valid YAML.

If the new file is corrupt or contains contents that libyaml can't parse, this leaves MotoROS2 without a valid configuration file.

We should instead verify the new .yaml on the USB stick can be parsed and only then overwrite the SRAM file.

If parsing fails, post an alarm, do not overwrite anything.

This would result in the old settings remaining active, but in some cases this could actually help as at least MotoROS2 would not throw away a potentially working configuration.

The first startup, it connected to the agent. Then it took a LONG time to init each control group. During that initialization, it disconnected from the agent. The listening script didn't indicate why it disconnected.

Eventually I got the expected alarm. But it took a while to init all four groups and I was on the verge of panic.

This should be improved. (or made unncessary).

The excessive delay was noticed on an R1 S1 S2 S3 system.

Would it perhaps already help if we postpone connecting to the Agent until after the Controller struct has been initialised (ie: all system level / non-micro-ROS stuff has been initialised)?
That way there's at least not the confusion caused by (half) connecting and then timing out of the Agent connection and the weird interplay between alarms and all the micro-ROS stuff going on.

Probably. But it would need some refactoring, as Controller init relies on the agent.

The FollowJointTrajectory action server in ros_control (joint_trajectory_controller) allows clients to request trajectory execution to start at a specific time in the future instead of immediately upon reception of the goal.

This is done by setting trajectory.header.stamp to something other than 0.

See wiki/joint_trajectory_controller/UnderstandingTrajectoryReplacement for a (terse) discussion of this functionality (note: that page is mostly about how the joint_trajectory_controller performs trajectory replacement or blending, that's not what I link it for here).

As MotoROS2 and the ROS 2 host PC sync their clocks, we could consider supporting this.

The 'dwell' time this results in can be calculated as goal.trajectory.header.stamp - current_controller_time.

As mentioned in the Known issues & limitations section of the README (here), MotoROS2 currently appears to suffer from a small memory leak.

Testing shows the following values for used and free memory after several consecutive connect and disconnect cycles with a Galactic micro-ROS Agent:

Initialization complete. Memory available: (962992) bytes. Memory in use: (85584) bytes
Initialization complete. Memory available: (962992) bytes. Memory in use: (85584) bytes
Initialization complete. Memory available: (962552) bytes. Memory in use: (86024) bytes
Initialization complete. Memory available: (962280) bytes. Memory in use: (86296) bytes
Initialization complete. Memory available: (962280) bytes. Memory in use: (86296) bytes
Initialization complete. Memory available: (962280) bytes. Memory in use: (86296) bytes
Initialization complete. Memory available: (962256) bytes. Memory in use: (86320) bytes
Initialization complete. Memory available: (962224) bytes. Memory in use: (86352) bytes

As a table:

No changes to the config file between reboots dis-and-re-connects.

It's unclear what causes this at this point.

We have a set of support packages available over at gavanderhoorn/motoman@ros2.

More will be added in the future, and the changes will be merged upstream.

Note these support packages still use the old joint name convention from MotoROS1 (ie: joint_l_s, etc). This is no longer needed with MotoROS2, and the names will be changed to the more generic joint_1, joint_2, etc.

See also Can names of joints be changed? in the FAQ.

As per subject.

The current implementation of the FollowJointTrajectory action goal validation does not check whether incoming JointTrajectorys have duplicated joint names in the joint_names field.

This could allow malformed trajectories to be considered OK to execute, while they should be rejected.

During beta1, a FollowJointTrajectory action server was implemented that uses the queue_traj_point service offered by MotoROS2 (docs) to stream JointTrajectorys of "infinite" length to the controller.

This works around the 200 point maximum trajectory length limitation which currently exists in MotoROS2 (known issue). Length of trajectories would then only be limited by the amount of memory available to the conversion node (the same limitation that applies to all ROS 2 nodes).

This node was never publicly released. It should be made available, to avoid duplication of effort and to avoid different implementations of such nodes offering different user experiences.

Getting MotoROS2: Fatal Error (subcode: 5) at startup due to rclc_node_init_with_options = 201. According to RCL this is "invalid name".

The config yaml does not have a custom name defined. And unfortunately #33 is not implemented.

motoros2_config:

---
# 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.50"
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

#-----------------------------------------------------------------------------
# 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:
#- [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: false

Last three of MAC is 0A:37:5F

[1686246952.68823862] [192.168.1.31:49225]: MotoROS2 0.1.0 - boot
[1686246952.68832254] [192.168.1.31:49225]: M+ libmicroros version: 'humble-20221102-dbg'
[1686246952.68837357] [192.168.1.31:49225]: PlatformLib version: 0.2.2
[1686246952.69634867] [192.168.1.31:49225]: No new configuration file found on CN102 USB drive.
[1686246952.69658685] [192.168.1.31:49225]: Checking configuration file: motoros2_config.yaml
[1686246952.80940700] [192.168.1.31:49225]: Config: agent_ip_address = 192.168.1.50
[1686246952.80963087] [192.168.1.31:49225]: Config: agent_port_number = 8888
[1686246952.80969644] [192.168.1.31:49225]: Config: sync_timeclock_with_agent = 1
[1686246952.80986404] [192.168.1.31:49225]: Config: stop_motion_on_disconnect = 1
[1686246952.80994272] [192.168.1.31:49225]: Config: publish_tf = 1
[1686246952.81012607] [192.168.1.31:49225]: Config: namespace_tf = 1
[1686246952.81279826] [192.168.1.31:49225]: Config: log_to_stdout = 0
[1686246952.81306601] [192.168.1.31:49225]: Config: executor_sleep_period = 10
[1686246952.81313133] [192.168.1.31:49225]: Config: action_feedback_publisher_period = 20
[1686246952.81330657] [192.168.1.31:49225]: Config: controller_status_monitor_period = 10
[1686246952.81341267] [192.168.1.31:49225]: Config: robot_status = sensor_data
[1686246952.81348944] [192.168.1.31:49225]: Config: joint_states = sensor_data
[1686246952.81363964] [192.168.1.31:49225]: Config: tf = default
[1686246952.81368661] [192.168.1.31:49225]: Waiting for robot alarms to clear...
[1686246955.31549644] [192.168.1.31:49225]: RMW settings 1: 1000; 0; 1000; 256; 256; 512
[1686246955.31571889] [192.168.1.31:49225]: RMW settings 2: 1; 1; 30; 15; 30; 1; -1
[1686246955.31579876] [192.168.1.31:49225]: RMW settings 3: 60; 120; 100; 100
[1686246955.31585240] [192.168.1.31:49225]: Using ROS domain ID: 0
[1686246955.31591654] [192.168.1.31:49225]: Using client key: 0x790A375F
[1686246955.31598020] [192.168.1.31:49225]: Attempting to connect to Micro-ROS PC Agent (at udp://192.168.1.50:8888)
[1686246956.33997822] [192.168.1.31:49225]: Found Micro-ROS PC Agent
[1686246956.34515023] [192.168.1.31:49225]: rclc_support_init_with_options = 0
[1686246956.34523773] [192.168.1.31:49225]: remap_rules str: ''
[1686246956.34540486] [192.168.1.31:49225]: len(remap_rules str): 0
[1686246956.34547782] [192.168.1.31:49225]: num parsed remap rules: 0
[1686246956.34554648] [192.168.1.31:49225]: faux argc: 2
[1686246956.34561539] [192.168.1.31:49225]: rcl_parse_arguments = 0
[1686246956.34569979] [192.168.1.31:49225]: rclc_node_init_with_options = 201
[1686246956.36735678] [192.168.1.31:49225]: motoRosAssert: MotoROS2: Fatal Error (subcode: 5)

Ran into this while testing #27.

With motoros2_config.yaml setup to use LAN3 on a YRC1000 (or at least: using an IP address in the range configured on LAN3), the following are seemingly still based on the MAC of LAN2:

• micro-ROS client key
• generated MotoROS2 node name

As a user, I would expect anything based on MAC address to take that address from the NIC that is used to connect to the Agent.

tasks:

• add support for DX200 controllers to build system for M+ libmicroros (#18 (comment))
• add DX200 to VS project configurations and related support files (.mps)
  • Humble only (for now)
• add DX200 version of MotoROS_PlatformLib binary
• add DX200 version of ParameterExtraction binary
• add/replace mpCtrlGrpNo2GrpId(..)
• need to read config file from USB instead of SRAM
• investigate potential issues with mpGetEncoderTemp (might not be available on DX200 / certain YCP versions)
  • available since DN2.44 -> updated requirements in doc
• need to read robot calibration data
• need to add gettimeofday(..) support (introduced by #61)
  • no longer needed: #99

Known issues (from previous testing):

• the command to create the node is returning an error code RCL_RET_NODE_INVALID_NAME. (I haven't done any debug on it yet.)
  • has not been observed again yet
• SUBCODE_FAIL_NODE_INIT when calling rclc_node_init_with_options(..) (returns 1) (#49 (comment))
  • probably the result of an outdated Agent: #49 (comment)

We currently publish RobotStatus at the same rate as JointState.

That's unnecessary, and also different from how MotoROS1 did/does it.

High frequency publications come with drawbacks. They:

1. increase network traffic
2. increase load on the Agent
3. potentially increase latency of other publications
4. increase load on controller CPU (ie: retrieving the information needed for the message, populating and publishing it are not free)
5. increase CPU load for subscribers on the ROS 2 side (for topics > 100 Hz this can become quite significant)

With this in mind, combined with the fact the information carried by RobotStatus messages is largely static and/or changes (very) infrequently, we should reduce the publication frequency to something like 10 Hz as it was in motoman_driver.

Similar to #15.

tasks:

• add support for FS100 controllers to build system for M+ libmicroros
• add endianness config for Micro-CDR (here) and Micro-XRCE-DDS (here)
  • ran into an issue: micro-ROS/micro-ROS-Agent#197
  • and another/follow-up one: micro-ROS/micro-ROS-Agent#197 (comment)
  • work around / hack in place: #19 (comment)
• add FS100 to VS project configurations and related support files (.mps)
  • Humble only (for now)
• add FS100 version of MotoROS_PlatformLib binary
• add FS100 version of ParameterExtraction binary
• allow building MotoROS2 for FS100
• resolve missing mpCtrlGrpNo2GrpId(..) (see 06e7eb2 and 032bcb4)
• need to read config file from USB instead of SRAM (#49 (comment))
  • turns out FS100 does support SRAM, so just reuse YRC1 code for this
• work-around/remove use of mpGetEncoderTemp (not available on FS100: #49 (comment))
• need to read robot calibration data (e28fc7b, 4f31af5)
• don't report application info (see MotoROS1: here
• FS100 supports max 4 groups (here fi)
• no (direct) support for retrieving system date-time (mpGetCalendar(..))
• update documentation
  • 'supported' badge
  • installation instructions
  • troubleshooting
  • faq

In Galactic, the default RMW has changed from Fast DDS to Cyclone DDS.

During testing, communication failed. Once I stopped the daemon and ran export RMW_IMPLEMENTATION=rmw_fastrtps_cpp everything worked fine.

After having discussed this over at ros2/rmw_cyclonedds#184 it appears this is a much wider problem. It's not just Fast-DDS vs Cyclone, but it's very likely all currently available DDS-based RMWs are incompatible.

Labeling as a bug.

It's not a bug here, or something we can control, but it's something users don't expect, causes MotoROS2 to not work with anything other than Fast-DDS and we will get support requests related to this.

With motoros2_config.yaml setup to use LAN3 on a YRC1000 (or at least: using an IP address in the range configured on LAN3) it appears debug log messages are only sent to LAN2.

Without LAN2 having a connection, no messages will be received.

If the action client doesn't accept the goal-request result message, then the server (MotoROS2) will be unable to process any future goal-requests.

I think this is an issue in micro-ros; not motoros. More testing needed.

To reproduce, simply have the client send a goal-request and then immediately terminate without accepting the response.

If the home position is not set, or the home position needs to be checked, the controller refuses to start INFORM jobs.

For MotoROS2 specifically, this means that start_traj_mode & start_point_queue_mode fail with:

$ ros2 service call /start_traj_mode motoros2_interfaces/srv/StartTrajMode
requester: making request: motoros2_interfaces.srv.StartTrajMode_Request()

response:
motoros2_interfaces.srv.StartTrajMode_Response(result_code=motoros2_interfaces.msg.MotionReadyEnum(value=108), message='The INIT_ROS job has not started. Please call start_traj_mode service')

There is no indication on the pendant as to "why" the job failed to start.

It is unclear whether this issue can be detected, or whether MotoROS2 can provide a better error message.

The current installation instructions are strictly for the standard pendant. These should be updated to include the Smart Pendant.

We have an extensive section on MotoROS2 error and alarm codes, and some hints in the FAQ, but we don't have anything providing guidance on how to deal with problems on the (micro-)ROS side.

Subjects to include:

• misconfigured RMW_IMPLEMENTATION (doc)
• mismatching ROS_DOMAIN_ID
• seemingly no data received by subscriber(s): possible QoS mismatches
• 'disappearing' or 'ignored' FollowJointTrajectory action goals: message too big (doc)
• mismatched micro-ROS Agent version (ie: MotoROS2 Galactic with a Humble Agent, or vice-versa)
• using the vanilla Micro-XRCE-DDS Agent instead of the micro-ROS Agent (😳)
• missing Yaskawa-Global/motoros2_client_interface_dependencies, or forgetting to source the appropriate (local_)setup.bash

etc

we might want to make sure trajectories can "time-out" while they are being executed.

I haven't checked the current implementation, but checking for time-tolerance should preferably be independent from trajectory execution (as in: we shouldn't just check for goal time violation at the end of the trajectory, but always).

Complexity here would be to figure out what to do when the robot is still in motion.

We'd need to initiate some sort of controlled stop, or generate a stop trajectory and replace the currently executing trajectory.

Low-priority, but technically, static transforms (ie: those that do not change over time) should be published on the /tf_static topic.

The QoS of that topic is also supposed to be different, mimicking a ROS 1 'latched' topic (ie: late joiners always receive the last published msg(s), even if they were published in the past). I believe that would be KEEP_ALL and TRANSIENT_LOCAL (but we'd have to check).

In regular ROS 2, this is all handled by the TF BroadCaster class, but we don't have that in RCLC.

To address this issue, we'd need to add an additional publisher, on topic /tf_static, with the correct QoS, and use it to publish flange->tool0 on that publisher alone -- once. (Micro-XRCE-)DDS will then take care of 'republishing' it for us if/when nodes require it.

The main benefit is reduced network traffic and less msg callbacks on the receiving side (as static transforms are only published once).

Debug UDP broadcasts should include the time they were sent:

As discussed in #63 (#63 (review)).

Similar to MotionNotReadyCode, create a ROS 2 .msg (in motoros2_interfaces) to store the values of the members of the Init_Trajectory_Status enum and the corresponding human-readable descriptions.

Then replace all references to those enum members as well as the magic strings with their equivalents from the .msg.

There's a LOT of red squiggles indicating code errors. However, this builds just fine.

I suspect that either the order of folders in the intellisense-search-path is incorrect, or it's caused by the monolithic MotoROS2.h that includes everything in one place.

Simple Connect is a standard product that we install on all arc welding robots in the Americas. We have also started putting it on some bare-arm systems if the user order certain peripheral equipment.

It probably won't get installed on a ROS system. But I want this note here for the future, if it ever does happen.

There is not enough SRAM storage (USER DEFINED FILES) for both the SC files and the MR2 config yaml.

While working on #61, @SejalBehere noticed that the year was reporting 2022. It turns out the YRC was configured with the wrong date. But, I thought rmw_uros_epoch_nanos was supposed to compensate for that. (The agent PC is set to 2023.)

We'll need to do some more testing later. There are other issues with the YRC in question. Perhaps this is an side effect.

Perhaps we should be checking a return code from rmw_uros_sync_session

After re-enabling the last-pt-in-a-trajectory-must-have-0-acceleration check here, I submitted a trajectory generated by MoveIt that apparently did not have the final point with an acceleration == 0.

MotoROS2 debug log showed:

The final point in a trajectory must specify a target acceleration of '0'.

but the ROS 2 / MoveIt log only shows:

Controller 'follow_joint_trajectory' failed with an unknown error: Trajectory initialization failed. Generic failure."

It would be nice(r) to provide the more descriptive error message, like we do for other errors.

This is on the roadmap as:

integration with ROS logging (rosout)

Low priority, as we already have the debug logger, but this could potentially be a nice way to integrate MotoROS2 even more with ROS 2.

In order to post useful error messages and alarms, MotoROS2 should be able to parse corrupted and/or malformed config .yaml files.

The configuration parser has been extensively tested with valid data, but more testing is needed to make sure it is able to handle invalid data and corrupted files as well, and to which degree.

On an R1+R2+S1 system, the /joint_states topic does not publish.

I did check the size of the joint_states message with R1+R2+S1. It was somewhere around 1100 bytes. So I don't think the size of the message is a problem.

Tested R1 S1 S2 S3 for other reasons. It worked ok. So it's not the number of groups. But it's still possible it's the number of axes.

I have not checked yet to verify if the publish API is returning an error code.

Ros_StaticAllocationBuffer_FJTgoal is currently configured to be SIZEOF_BUFFER_FTJGOAL (2000000) bytes.

This number is not based on anything other than it needed to be "big enough" when the code was first written.

A better size for the buffer should be determined.

Dynamic memory is not an option for this buffer.

MotoROS2 currently has a hard-coded set of IOs it uses for signalling internal application status:

These indices should be made configurable, to allow users with conflicting IO assignments to use MotoROS2 without having to rebuild the application.

Just noticed this mentions DX100. Bad copy/paste from MotoROS1.

https://github.com/Yaskawa-Global/motoros2/blob/5c63671df6c6905a5e5f0aa463bec18cef5087c8/doc/troubleshooting.md#alarm-8003100---111

I'll submit a fix later this afternoon.