Error Reporting Improvements

[marip8]

We ran into some (mostly self-induced) issues configuring and testing the MotoROS2 driver on some of our robots that I wanted raise awareness about to either:

• document the solution if it exists, or
• brainstorm good solutions to address these issues

Improve string message reporting of errors

1. We accidentally called the joint_trajectory_action (through the point queueing service via the proxy node) with incorrect joint names. The string error message we ultimately received (via the proxy node, which appears to simply log the error message) was: Failed to initialize the streaming trajectory.

2. We also accidentally called the joint_trajectory_action (through the point queuing service via the proxy node) with additional joint names for joints that did not exist on the controller. We received the same error message: Failed to initialize the streaming trajectory

We were ultimately able to discover the issue via the provided debug script and debug messages, but even that was somewhat difficult to parse through.

20240314T120315_motoros2_debug_log.txt

In both of these cases, it would have been much more useful to receive a message like Trajectory includes joint names that are unknown to the controller: [list of unknown joint names]. Known joint names include: [list of known joint names].

I suppose we probably could have checked the result code enumeration (which we did not) and tried to generate our own appropriate error message, but I generally rely on the server node itself to give a very specific string error message when possible since it is the one identifying the issue

Many error conditions seem to be logged by debug messages, but it would be nice to capture and return those messages as string error messages to the joint trajectory action and the point queuing service

MotoROS2 YAML configuration introspection

AFAIK there is no way to introspect the configuration of MotoROS2 on the controller itself. In my case, one of my colleagues had previously configured the robot with a specific ROS domain ID and agent IP address that I didn't know about. As a result it took me a while to figure out how to even connect to the robot.

It would be nice if there were a simple MotoROS2 GUI "panel" on the teach pendant that could display this information (and potentially let users with the correct privileges update it).

[gavanderhoorn]

Thanks for posting this.

Something that immediately caught my eye:

We were ultimately able to discover the issue via the provided debug script and debug messages, but even that was somewhat difficult to parse through.

looking at the log you include, I believe this is caused by a version of MotoROS2 which is either older or newer than the version of the debug listener script that was used. There have been a few changes to that script, specifically to the way it parses the timestamps, and if the version of MotoROS2 doesn't format log lines as expected, the listener script will appear to be 'cutting up' lines incorrectly.

Could you perhaps check the version of MotoROS2 on the controller (you can find this in the PANELBOX.LOG file fi), and the version of the debug listener script on the PC/laptop that was used (a git rev-parse HEAD would suffice)?

[marip8]

@DavidSpielman @BryanMqz can you gather this information requested above?

[DavidSpielman]

@gavanderhoorn Where is the PANELBOX.LOG file located? I have tried to find this answer online, but I haven't been successful.

[gavanderhoorn]

you should be able to save that to a USB stick from the pendant by creating a backup and selecting at least system data.

[DavidSpielman]

We have the 0.1.1pre version of MotoROS2 running on our DX200 controller.
The version of the debug listener script is commit c786547.

[gavanderhoorn]

Yes, that would cause the log to be interpreted and presented differently than the debug listener expects, resulting in the lines getting cut up. This version of the debug listener probably works better with your version of MotoROS2.

Btw: 0.1.1pre is rather old. I don't know why you have a pre version installed, perhaps Doug (Smith) build the binary from source for some reason.

You may want to consider updating, considering the many changes that have been merged since 0.1.1 was released (and yours is even older).

If you keep a copy of the .out you have installed right now and a copy of the configuration file, you should be able to revert to your custom 0.1.1pre at any time.