To test the usefulness of the xarm-commander tool, create some example scripts that execute a few commands using the CLI tool.

CLI11 provides CLI::App::pre_callback() which allows injecting a code after parsing and before callbacks.
The gRPC client for the xArmAPI service can be initialized with this since it is required for all the subcommands in xarm-commander – otherwise, the client initializations are redundant.

Related to #32

Resolve following problem:
an exception may be thrown in function 'main' which should not throw exceptionsclang-tidy(bugprone-exception-escape)

Extend the README file to include instructions on how to use the xarm-commander and a list of known issues and their solutions.

Use the Oneof keyword in the .proto description to handle the polymorphism of the motion methods.
See proto3 docs for further information.

This may be used for the following methods:

• set_position()
• set_tool_position()
• set_servo_angle()

The Dockerfile for xarm-grpc-service should come in handy to validate the build as well as cleaning up the build process.

In order to use the CLI tool with other frameworks/languages (e.g. Nodejs) the output of the xArm SDK must be disabled/formatted. In the best case, this complies with the setting for multi-level logging, which is determined by the flags. (see issue #4)

Add CLI options to be able to format and define output (e.g. Logfile) for logging information.

By setting a logging destination, the additional information (info, debug, eval) can be retrieved from an external file if the xarm-commander is used in an integrated way (e.g. called by Nodejs).

For linking generated gRPC sources with xarm-commander, it's better to use cmake.

Run the linter on push to main/pull requests automatically.

Best way to return values, log information/debug messages.
Define syntax for return values, response code and logging messages. (maybe use json)

Are we using default values (e.g. default position x = home position(x)), and if so, where/how are these defined/managed.

Some properties (let's call them controller properties) such as angles are stored on the controller and therefore are fetched by sending a request to the controller.

Others (let's call them service properties), like last_used_angles are only stored as a property of the XArmAPI* api object (xARM-CPLUS-SDK) and are therefore not fetched from the controller.

Controller Properties are consistent over different sessions (session = initialization =>disconnect), on the other hand, Service Properties are reset every time a new session is started by calling initialize.
This is probably desired but still might create some problems (e.g. see Issue #44 ).

This might also be interesting for multi-user applications.

Needs to be further discussed and investigated..

For wot-servients to interpret the capability of xArms (i.e., the C++ SDK/xarm-commander), it's a nice feature to have an option to print the capabilities for each command in a machine-readable format (e.g., JSON-LD).
Implement this by either a single global command or an option for each available command.

Sending multiple getVersion requests may result in breaking the gRPC connection, resulting in the following error message:

[XAPIDeamon] stderr: [libprotobuf ERROR /home/jo-bru/grpc/third_party/protobuf/src/google/protobuf/wire_format_lite.cc:577] String field 'xapi.Version.version' contains invalid UTF-8 data when serializing a protocol buffer. Use the 'bytes' type if you intend to send raw bytes.

sending a set_servo_angle for a single angle right after initialization results in moving the robot with the given angle AND other all angles to the home position.
This can be recreated by doing the following:

xarm-commander initialize -x 130.82.171.9
xarm-commander set_position
xarm-commander disconnect
xarm-commander initialize -x 130.82.171.9
xarm-commander set_servo_angle -i 1 -a 20

Changing the default_is_radian value can be dangerous, since some motion commands use last_used_x as default values.
As described in #45, last_used_x is a Service Property and will therefore not be adapted to the unit change (deg <=> rad).
This can lead to fast and unwanted movements (e.g., speed unit is deg/s <=> rad/s).

The SetDefaultRadian command will therefore be deactivated for now.

Apply multi-level logging which can be set by using different flags: -v, -vv, etc.

Measure time consumption for different commands with and without connection establishment ( in relation to RTT).

Include external libraries (e.g. CLI11, easylogging++) properly => sub-moduled or prepared by the users.
[optional] create CMake files.

To evaluate the latency in the AC power box, we could use the serial socket instead of the TCP through Ether.

The Cmdnum property and its methods (e.g. GetCmdnum) have to be tested and further investigated.

The following methods were yet not tested:

• Reset
• EmergencyStop

Move formatting/linting instructions in README.md to CONTRIBUTION.md.
And delete section: "Pull Requests and Feature Branches" inCONTRIBUTION.md.

Refactor the current C++ xarm-commander implementation by using the clang-tidy linter.

• xarm-grpc-service: repo including xarm-deamon and .proto definitions
• wot-fx/../nodewot-xarm: implements a gRPC client using the xarm-grpc-service as a submodule (to get the .proto definitions?)
• xarm-commander: two options
  • seperate repo using the xarm-grpc-service as a submodule
  • or: included in xarm-grpc-service as tool or example

Originally posted by @jo-bru in #32 (review)

The GetVersion request returns the version with trailing zeros.

"h2,v1.6.5\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000"

Due to the complex dependency, we need to validate the build on the main branch always succeeds.
Add a workflow for build test including the generation of grpc sources from the proto file.

Create/investigate Typemaps to support pointers and arrays.

From the discussion in #32 perhaps it makes more sense (and even attractive) to rename this project to "xarm-grpc" or something such?

Implement 2nd solution for overloaded functions: using %rename to support overloaded functions.
See corresponding section

The dependencies are currently handled manually via the submodules. However, integrating them with cmake or bazel is preferable.

Once we find a way to daemonize the xArm connection handler, we will implement server command to start establishing the connection with an xArm robot.

The default mechanisms must further be investigated.

Related to Interactions-HSG/wot-fx#39.

Calling the get_robot_sn() using the following doesn't work (i.e., returns an empty value).

unsigned char robot_sn_char[40];
status_code = api->get_robot_sn(robot_sn_char);

The GetRobotSN was introduced in d73658f.

If more than four commands are sent in parallel, some commands will fail.

Example Error: Error: Command failed: xarm-commander -i 130.82.171.9 -v get_position

This error can be reproduced by calling more than four commands in parallel running for example the following:

Promise.all([
            sendCommand(['-i', IPaddress, '-v', 'get_version']),
            sendCommand(['-i', IPaddress, '-v', 'get_state']),
            sendCommand(['-i', IPaddress, '-v', 'get_state']),
            sendCommand(['-i', IPaddress, '-v', 'get_state']),
            sendCommand(['-i', IPaddress, '-v', 'get_position'])]);
    })

To understand this error, it should be investigated how many connections can be processed simultaneously by the CPLUS SDK.

Implement error handling to throw an error when the responseCode is not 0 (i.e., the command was not successful).
Return the responseCode without the responseValue by using stderr (?).