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.

[ahundt]

I think it starts at all 0 and rotates the last joint back and forth. I haven't run it in a while. You started the grl_driver and did it indicate it received anything from your computer?

Are you able to ping both the java and FRI IP address from your computer?

[ahundt]

We checked, and the failed verification only relates to a feature that isn't in use right now. You can comment that line, we're working on a fix to that part.

Also, if you're getting the EXCELLENT quality message that means the connection is good. It does appear there is a bug in that FRI test code so it no longer rotates the last joint for some reason. We are also looking into that.

[efipsom]

I'm guessing the vector jointStateToCommand should not be all zeros as that's what is copied to the commandedpos. But even if I change the last cell of the vector the joint does not move.
I'm more concerned as to why I don't even get any FRI data. It appears that the haveNewData variable remains false all the time even though I'm getting the EXCELLENT quality message on the smartpad.

[ahundt]

Yeah we've been able to reproduce the issue. However, the v-rep plugin version is working correctly for us. We're looking into the issue now. Sorry for the delay!

[ahundt]

@efipsom Could you try the v-rep scene or the java (non-FRI) control to verify that is working for you in that case?

We've been running using the v-rep scenes every single day with both FRI and JAVA control modes without issue, so we know the API works. We have been able to reproduce your problem, but we haven't been able to completely solve the test app's issue, unfortunately. It might also be worth looking at the history of the test file, I usually make a commit that says "it works!" or something like that. There might be an older version without this issue.

[efipsom]

Ok I'll look into the history of the test file.
Can you give me a few instructions on how to test/run the v-rep scenes with FRI control mode?

[ahundt]

you just need to make sure

1. v-rep is installed
2. there are symlinks from every dynamic library (.so in linux) in the build folder to the v-rep folder
3. there are symlinks from every lua file to the v-rep folder
4. open the .ttt file in v-rep
5. it should load, enable the realrobot v-rep script
6. check that the robot has lots of space and the red button is ready
7. hit play
8. robot moves!

let me check how up to date the instructions are on the doc page. We're still working on getting the latest update ready for release so you can use it. Sorry it has been taking so long but we're making progress now.