search

Interactions-HSG / xarm-grpc

A command-line interface for xArm-C++-SDK to interact with UFACTORY xArms
Eclipse Public License 2.0
5 stars 0 forks source link

feat: xArmAPI daemonization with gRPC #32

Closed iomz closed 3 years ago

iomz commented 3 years ago

This (somewhat destructive) PR implements #18 As updated in README.md, xarm-commander now interacts with a new program "xarm-daemon" to run commands via its xArmAPI object.

In addition, the following changes were made:

Resolves #5 Resolves #18 Resolves #31

iomz commented 3 years ago

I guess I still need to fix the CI Action as well as some integrity checking in the rpc serivces.

iomz commented 3 years ago

Ha! Passed the check. Calling it a day.

jo-bru commented 3 years ago

Oh wow, that's a lot!:sweat_smile: Thank you very much! I've tried to get it to work on my system but have not yet succeeded (some building errors). I'll first focus on the mid-term presentation and then try to make it work.

About the system structure: I like the usage of gRPC for internal communication, but I guess we could then directly send the commands from the Servient implementation (nodewot-xarm) to the connection manager (xarm-deamon) (i.e. the Servient implements the gRPC client). In this case, we would not need to include the xarm-commander in the software stack and don't need to start a separate childProcess for each command. The xarm-commander might be still interesting as a low-layer/ non-WoT API. Does this make sense?

iomz commented 3 years ago

I've tried to get it to work on my system but have not yet succeeded (some building errors).

I'm interested in your building errors. Can you share the problem? I might be able to solve it rather quickly – I've seen it all yesterday all day long lol

I'll first focus on the mid-term presentation and then try to make it work.

Yes, please do so.

About the system structure: I like the usage of gRPC for internal communication, but I guess we could then directly send the commands from the Servient implementation (nodewot-xarm) to the connection manager (xarm-deamon) (i.e. the Servient implements the gRPC client). In this case, we would not need to include the xarm-commander in the software stack and don't need to start a separate childProcess for each command. The xarm-commander might be still interesting as a low-layer/ non-WoT API. Does this make sense?

That's indeed a great and more interesting idea than the Servient as just a shell executor (which I initially accused of the abuse but somehow supported later). I was too narrow-sighted and didn't realize what I did. Let's steer to the direction with gRPC😄 However, the xarm-commander program still serves two additional values: 1. driver for developing and testing the gRPC service itself and 2. tool for the latency measurement.

jo-bru commented 3 years ago

I'm interested in your building errors. Can you share the problem? I might be able to solve it rather quickly – I've seen it all yesterday all day long lol

Now the gRPC build process somehow worked, but when I try to build the xarm-commander and xarm-deamon as described here I get the following error: error while loading shared libraries: libgrpc_plugin_support.so.1.41: cannot open shared object file: No such file or directory

For the gRPC installation, I had to add the -DBUILD_SHARED_LIBS=ON option. I'm not sure if that was the right way..

jo-bru commented 3 years ago

That's indeed a great and more interesting idea than the Servient as just a shell executor (which I initially accused of the abuse but somehow supported later). I was too narrow-sighted and didn't realize what I did. Let's steer to the direction with gRPC😄 However, the xarm-commander program still serves two additional values: 1. driver for developing and testing the gRPC service itself and 2. tool for the latency measurement.

Great, I'll also briefly discuss this in the mid-term presentation.

iomz commented 3 years ago

Now the gRPC build process somehow worked, but when I try to build the xarm-commander and xarm-deamon as described here I get the following error: error while loading shared libraries: libgrpc_plugin_support.so.1.41: cannot open shared object file: No such file or directory

For the gRPC installation, I had to add the -DBUILD_SHARED_LIBS=ON option. I'm not sure if that was the right way..

Hmm, that's something I haven't seen. -DBUILD_SHARED_LIBS=ON for the cmake on https://github.com/grpc/grpc right?

jo-bru commented 3 years ago

Hmm, that's something I haven't seen. -DBUILD_SHARED_LIBS=ON for the cmake on https://github.com/grpc/grpc right?

Yes, I've found this here: https://github.com/grpc/grpc/blob/master/BUILDING.md#building-with-cmake

iomz commented 3 years ago

Yes, I've found this here: https://github.com/grpc/grpc/blob/master/BUILDING.md#building-with-cmake

Meaning, you are building gRPC on Windows? 😅

jo-bru commented 3 years ago

Meaning, you are building gRPC on Windows? 😅

No, on WSL2. Like in section Linux/Unix, Using Make described:

If you want to build shared libraries (.so files), run cmake with -DBUILD_SHARED_LIBS=ON.

iomz commented 3 years ago

No, on WSL2. Like in section Linux/Unix, Using Make described:

If you want to build shared libraries (.so files), run cmake with -DBUILD_SHARED_LIBS=ON.

Ok, why did you need the .so? My environment only has libgrpc_plugin_support.a it seems.

jo-bru commented 3 years ago

Ok, why did you need the .so? My environment only has libgrpc_plugin_support.a it seems.

I'm honestly not sure why..I just had some errors that some libraries can't be found (unfortunately I don't have the exact error messages anymore) But I'll try it again later this week..

iomz commented 3 years ago

I'm honestly not sure why..I just had some errors that some libraries can't be found (unfortunately I don't have the exact error messages anymore) But I'll try it again later this week..

Yes, please do so 😉 By then perhaps I'll get the GitHub Action for the build test working.

jo-bru commented 3 years ago

Nice, it works. It took around 30ms to get the version, when running it locally from Basel

Just tested it locally on nano: seems to take exactly 19ms when executing time xarm-commander get_version

iomz commented 3 years ago

Nice, it works. It took around 30ms to get the version, when running it locally from Basel

Just tested it locally on nano: seems to take exactly 19ms when executing time xarm-commander get_version

I created the v0.1.0 release for the current main before merging this PR. See https://github.com/Interactions-HSG/xarm-commander/releases/tag/v0.1.0

jo-bru commented 3 years ago

Ah great, thank you!