ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Have you looked at Unity blogs: Robotics simulation in Unity? Section 3, Connecting your simulation to ROS states:
Now that the robot is in the Unity Editor, we should test our motion-planning algorithm, running in a set of ROS nodes. To support this, we need to set up a communication interface between Unity and ROS. Unity needs to pass messages to ROS that contain state information — namely, the poses of the robot, target object, and target location — along with a planning request to the mover service. In turn, ROS needs to return a trajectory message to Unity corresponding to the motion plan (i.e., the sequence of joint positions required to complete the pick-and-place task).
I haven't myself tried this out but the Unity package ROS-TCP-Connector
and ROS package ROS-TCP-Endpoint
look useful to establish the bridge between Unity and ROS. On the Unity side, a C# script could make a service request, in response to which, ROS sends back the trajectory as the service response:
[..] makes a service request to the MoveIt motion planner. The service request includes the current pose of the robot, the pose of the target object, and the target location. When MoveIt receives the planning request, it attempts to compute a motion plan. If successful, the service returns the plan, i.e., a sequence of joint positions [..]
Depending on your use, you may not even need a service. Set up a publisher on the ROS side and a subscriber on the Unity side, and after the trajectory is computed ROS simply publishes it.
2 | No.2 Revision |
Have you looked at Unity blogs: Robotics simulation in Unity? Section 3, Connecting your simulation to ROS states:
Now that the robot is in the Unity Editor, we should test our motion-planning algorithm, running in a set of ROS nodes. To support this, we need to set up a communication interface between Unity and ROS. Unity needs to pass messages to ROS that contain state information — namely, the poses of the robot, target object, and target location — along with a planning request to the mover service. In turn, ROS needs to return a trajectory message to Unity corresponding to the motion plan (i.e., the sequence of joint positions required to complete the pick-and-place task).
I haven't myself tried this out but the Unity package ROS-TCP-Connector
and ROS package ROS-TCP-Endpoint
look useful to establish the bridge between Unity and ROS. On the Unity side, a C# script could make a service request, in response to which, ROS sends back the trajectory as the service response:trajectory:
[..] makes a service request to the MoveIt motion planner. The service request includes the current pose of the robot, the pose of the target object, and the target location. When MoveIt receives the planning request, it attempts to compute a motion plan. If successful, the service returns the plan, i.e., a sequence of joint positions [..]
Depending on your use, you may not even need a service. Set up a publisher on the ROS side and a subscriber on the Unity side, and after the trajectory is computed ROS simply publishes it.