Pick and place demo: robot not moving in part 3 about unity-robotics-hub

[hyounesy]

Hi, I don't see any issues in the ROS console output. Do you see any errors on the Unity Editor console?
Looks like the message from Unity was sent to MoveIt without issue, but MoveIt failed to send a message back to Unity.
One possibility is that a firewall is blocking some connections from the WSL environment. Are you able to ping your local machine's IP address from WSL? If not please try adding a firewall rule to allow incoming connections from your WSL to your local machine?

[KKassem]

Thanks for responding.

You're right. I had a feeling this might have been a firewall issue. Ping wasn't possible, and so I tried temporarily disabling the firewall on Windows for the test, and the ping managed to go through. However, the arm still doesn't move.

Checking the Unity console, it has an error reading

No data available on network stream after 10 attempts.
UnityEngine.Debug:LogError (object)
ROSConnection/<SendServiceMessage>d__21`1<RosMessageTypes.NiryoMoveit.MoverServiceResponse>:MoveNext () (at Library/PackageCache/com.unity.robotics.ros-tcp-connector@ab45157ad3/Runtime/TcpConnector/ROSConnection.cs:129)
UnityEngine.UnitySynchronizationContext:ExecuteTasks ()

This error shows with the firewall turned off. Pings go through normally. I checked the TCP connection by running telnet on port 5005, which also seems to be running normally.

Edit: I also tried setting the Override Unity IP Address parameter with the address from which ROS was receiving the handshake. That also didn't work.

Edit 2: The above error is always immediately followed by a "Trajectory returned." log entry.

[hyounesy]

Here are a couple things to investigate:

• What IP address did you set in the unity address override? It might be because you are not using the correct IP addresses for this. I believe in the WSL that has to be set manually.
• See if the solution proposed for this similar issue works for you. In short: Use ifconfig inside WSL to find the address of the eth0 adapter, use ipconfig on the windows side to find the corresponding vEthernet WSL adapter and make sure those values are what are used wherever IP addresses are needed.

Let us know if any of these methods resolve your issue!

[mrceresa]

Did you check if it is the timeout?

I had the same error when my machine took 11 seconds to calculate the trajectory. I put it to 20 attempts and it worked. You can change it in the ROS Settings.

[hyounesy]

Hello @KKassem , just wanted to check if you were able to resolve the issue above, before we close the issue.

[KKassem]

Did you check if it is the timeout?

I had the same error when my machine took 11 seconds to calculate the trajectory. I put it to 20 attempts and it worked. You can change it in the ROS Settings.

It wasn't a time out afaik because the gripper opens at the end.. changing the number of attempts did nothing.

It was too frustrating to deal with, so I think I will try further with the Docker approach. The WSL path just doesn't seem robust enough at the moment if it's this undeterministic. Thanks for all your help.

[peifeng-unity]

Thank you @KKassem for your feedback. Hope everything would go well with the Docker approach.

I will close this issue. Please feel free to reopen it if you have more questions.