Is it possible to launch the interface in sim without Gazebo?

[karthikm-0]

Hi,

Thank you for the awesome set of packages! I'm trying to use ROS# to control my arm in Unity using a joystick but want to leverage the IK solutions built-in to the panda_robot package. However, I do not require the extra overhead through the Gazebo simulation (since my robot moves in Unity). I tried to launch using ./franka.sh sim but was greeted with the error:

FrankaHW: Failed to initialize libfranka robot. libfranka: Connection error: Host not found

I'm wondering if this is indeed possible or would I still need to use the panda_simulator to launch the arm interface and then access the panda_robot IK methods?

Thanks!

[justagist]

Thanks for your kind words! The packages are currently written expecting realtime robot state data from either the real robot or the simulation (in the form of ROS topics/services). The panda_simulator package uses gazebo for all the physics computations and simulations for the robot. So it will not be possible to completely remove the dependency on gazebo, as it provides the physics engine required. You can however turn off the rendering to remove the graphics overhead by adding an argument: roslaunch panda_gazebo panda_world.launch gui:=false. This will disable the GUI but still simulate the robot without visualising. Another option would be to write another robot simulator in Unity which uses Unity's physics to perform the simulation and publish the robot state information in the same topics/services as panda_simulator. This should allow you to use the same interface packages (hopefully without too many issues!), and completely be independent of gazebo.

[karthikm-0]

Thank you for the advice! I ended up creating a service to request IK solutions from the Panda arm interface from my Unity sim. However, I think I may need to go the publisher/subscriber route since it may be too intensive. Do you have any thoughts on that?

[justagist]

I am not sure I understand what you mean by the publisher/subscriber route?

[karthikm-0]

Sorry, I meant that there are two approaches one could take to update the robot's state using joystick input. In the first, the input is sent from Unity via a service request and the solution is returned which updates the joint states (which is what I am currently doing).

The other approach involves publishing the user inputs and joint states to a topic and having a subscriber that takes these and constantly generates new joint angles in ROS, which the Unity robot can subscribe to and update based on.

Would the service approach be inefficient or too slow for such an application? In that case the pub-sub route makes a lot more sense. I suppose this is more of a general ROS question, but it pertains to IK solutions.

[justagist]

From your mentions about IK, I assume you want to control the end-effector of the robot in Unity using joystick input? In this case, why not use the IK solver that is already available in Unity? Why do you want to use an external solver such as the one being used by the PandaRobot package? Is it necessary for you to use ROS? You should be able to provide target poses for the end-effector in Unity, and the Unity IK solver should compute the required joint positions for the robot. This is going to be the most efficient in terms of speed and responsiveness, and possibly even in terms of finding optimal solutions.

Both the 'service approach' and the 'pub-sub' approach you mentioned have their issues if efficiency is your priority. Service requests are usually blocking, so the client code may stop till a solution is obtained from the server, which could cause delays. ROS topics route, on the other hand are more prone to loss in data, so quick motions of the robot might be troublesome. Furthermore, the IK solvers are not always the best way to control the robot's end-effector, especially over motions of longer distance. The solutions saturate, and sometimes even diverge depending on the use case. It can also be seen that the robot's motion drift over time as well depending on the allowed tolerance for the solver. The alternative and more accurate solution is to write a higher-level task space controller for the robot. However, even though this solution is much better in terms of accuracy and tracking, this may be overcomplicating the issue if the motion you have is simple (point to point motions with small distance between each).

In my opinion, if you don't really have to use ROS, I would suggest using the native IK solver in Unity which is quicker and in all possibility, much more efficient. If you still want to use an external library for IK, the solver I use (PyKDL) is based on a C++ library (KDL) which you can probably compile as a plug-in for Unity.

[karthikm-0]

Thanks a lot for the super detailed response! I'll definitely need to use ROS since I use motion planners and other useful libraries, but I think compiling KDL for Unity would make everything much more responsive.