Closed jo-bru closed 3 years ago
Sorry for the mess in the commit history:grimacing:
Just before reviewing the code
I was trying to redirect the output of the xarm-SDK to the logger (#5), but since it uses printf() instead of std::cout it's not trivial and must be solved by using pipes, I guess (which I do not understand yet).
How about we tweak the SDK and suppress/manipulate the nasty messages from the SDK? I forked the repo: https://github.com/Interactions-HSG/xArm-CPLUS-SDK
How about we tweak the SDK and suppress/manipulate the nasty messages from the SDK? I forked the repo: https://github.com/Interactions-HSG/xArm-CPLUS-SDK
Ah yes, that would be easier..
Finally, let's not use actual values as defaults 😄
What do you mean by that?
Ah, I guess I know what you mean (e.g. defaults for position x) => I'll change that after we implemented the server
command.
I've created an issue for this: #25
Ah no, it's about 130.82.171.9😉
For logging, I used the easylogging++ library as it's quite simple and supports verbose logging. Info, debug and evaluation messages can be logged by using the verbose levels (1,2,3) respectively. The verbosity level can be set by using the -v flag (e.g.
xarm-commander -vv get_state
=> has verbosity level 2 = debug). The response code and response values are returned withstd::cout
formatted as JSON (maybe this should be done by using an JSON support library).I'm not sure if using the verbose levels is the way to go, or if we need to use the INFO, DEBUG, etc. levels and implement the verbosity ourselves.
I was trying to redirect the output of the xarm-SDK to the logger (#5), but since it uses
printf()
instead ofstd::cout
it's not trivial and must be solved by using pipes, I guess (which I do not understand yet).This first logging implementation should solve #4, but I guess we'll have to rethink the approach after first integration tests with nodejs.