GRL installation issues

[efipsom]

I've been having some trouble installing GRL in Ubuntu 16.04.

1. Following the instructions in the install.md file and running ./grl_kuka.sh for the first time I get the following error:
   CMake Error at /usr/local/share/basis/modules/DocTools.cmake:1288 (message): Command sphinx-build not found! Either install Sphinx and/or set Sphinx-build_EXECUTABLE or disable BUILD_DOCUMENTATION.
   even though the package sphinx-build is already installed.

2. Is there a way to confirm that I have the Sunrise Connectivity suite installed? Is it shown anywhere in Sunrise Workbench? In the StationSetup.cat, I don’t see the “Interface for Rendering Standalone implementation” and “Tools and Models for Rendering VREP” even though my setup looks exactly as the one in the screenshot.

3. After copying the FRI-Client-SDK_Cpp.zip file in the grl/data folder and running ./grl_kuka.sh again I get the following error:
   CMake Error at /usr/local/share/basis/modules/CommonTools.cmake:2368 (message): Target name '/home/username/src/grl/build/FRI_Client_SDK_Cpp/example/SimulatedTransformationProvider/SimulatedTransformationProviderApp.cpp' is invalid.
   which is correct because this example was not in the original zip file. How can I overcome this?

Finally, you mention on the website that you recommend installing iiwa_stack in addition to grl for full ROS integration. From what I understand iiwa_stack does not actually use the FRI whereas grl uses it. Is that correct? My optimal setup would be to create a ROS node that calls the FRI functions. Should I install both grl and iiwa_stack?

Thanks in advance.

[ahundt]

Which version of FRI are you using? The most recent release works with 1.11.

For sunrise connectivity suite you will see the SmartServo, DirectServo and FRI code. If you have that FRI zip file you almost certainly have the connectivity suite.

I think the tools for vrep have been removed, perhaps also the rendering interface. I don't think they're super important for this setup.

In this case iiwa_stack is used for the URDF files and the configuration of MoveIT etc, while grl is used to actually drive the robot around. https://github.com/IFL-CAMP/iiwa_stack We already have a ROS node you can use in https://github.com/ahundt/grl/blob/master/src/ros/grl_kuka_ros_driver.cpp. I need to mention that we haven't run the ROS version in a while so a little tweaking might be necessary.

[ahundt]

In around 4-6 weeks we also hope to have a few additional FRI improvements ready and a new release. Commanding via FRI is still a bit experimental as of the latest release, but receiving via FRI and commanding via the JAVA control works very well and should have lower latency than iiwa_stack if that's what matters to you.

[efipsom]

Thanks for the clarifications regarding grl and iiwa_stack.
I'm using FRI 1.10 and since I also have the SmartServo, DirectServo code, I assume that I have the connectivity suite. Is there any suggestion as to how to overcome the errors I get when I run ./grl_kuka.sh?

[ahundt]

I think the most straightforward option would be to update to 1.11 since I couldn't test any problems you might encounter on 1.10.

The SimulatedTransformProviderApp.cpp file is just for example code, so the other option is to simply comment the lines that build SimulatedTransformProviderApp. However this may reveal yet another issue which might mean it is easier to update to 1.11.

[efipsom]

Commenting these lines caused more issues.
KUKA can upgrade our software to 1.13. Has grl been tested with this version?

[ahundt]

hmm sorry about that, only 1.11 right now. I've been planning to upgrade to 1.13 but haven't done it yet.

[ahundt]

I created a pull request with more recent changes:
#166

Can you see if this helps get you to the next step?

Here is how to get the changes on your computer:
https://help.github.com/articles/checking-out-pull-requests-locally/

[efipsom]

I checked out branch "logging" but I get the same error.

If I comment the lines that build SimulatedTransformProviderApp, I get undefined references to KUKA::FRI::TransformationContainer during make install.

[efipsom]

The "logging" branch didn't help but in the master branch if you:

1. Comment lines 120-123
2. Uncomment line 76

of file FRI_Client_SDK_Cpp.cmake, it's installing even with version 1.10.

[ahundt]

Cool thanks!
You mentioned via email that you don't have the flatbuffers jars. I believe I got them from here:
https://github.com/davidmoten/flatbuffers

[ahundt]

The script to install all the tasks components, including spacevecalg is at:
https://github.com/ahundt/robotics_setup/blob/master/robotics_tasks.sh

[efipsom]

Thanks. So grl is now installed and I'm trying to test FRI but the connection doesn't seem to be working. I'm running FRIHoldsPosition_Command.java on the SmartPad and KukaFRITest on the computer. The Linux terminal gives me:
[2018-06-05 13:07:43.844] [console] [error] Error sending packet to KUKA iiwa: ret = -1, len = 592 set commandedpos:[0, 0, 0, 0, 0, 0, 0] No new FRI data available, is an FRI application running on the Kuka arm? Total sucessful transfers: 622 Total attempts: 10001 Consecutive Failures: 17 Consecutive Successes: 0
The corresponding SmartPad screen is attached.

[efipsom]

What is the best way to test commanding positions via FRI? Set the driver to use as low_level_fri_class?

[ahundt]

Try running grl_driver on the teach pad, that should sit and wait for a connection.

You found the right test file, KukaFRITest.cpp, you'll want to use DriverToUse::kuka_driver_high_level_class, and make sure the strings for receive and send are set to "FRI" (this appears to be the default).

The high level class helps by connecting on the java side and telling the robot to switch to FRI mode.

[efipsom]

I'm now running grl_driver on the smartpad and the high level class on the FRI test and I get:
set commandedpos:[0, 0, 0, 0, 0, 0, 0][2018-06-05 17:30:26.592] [console] [info] re-extracted 0 joint angles: [] [2018-06-05 17:30:26.592] [console] [error] C++ KukaJAVAdriver Error: flatbuff failed verification. bufOk: false No new FRI data available, is an FRI application running on the Kuka arm?
Shouldn't the commandedpos be different than 0 for the last joint?
Also the same warning, as the previously attached photo, comes up on the smartpad about the possible connection problem.