How to control Franka independent of MoveIt?

[Director-of-G]

The assembly_screw script shows how to control Franka via MoveIt! However, MoveIt seems only support position control at low-level, which is not convenient for servo controllers with velocity output. We'd like to directly control Franka at velocity level (i.e., with Cartesian velocity or joint velocity command). How could this be resolved?

We tried rosservice call /controller_manager/load_controller "/joint_velocity_example_controller" and get ok: True , but there are no relevant ROS topics to send velocity command.

We refered to the MoveIt document which says

The servo node can publish trajectory_msgs/JointTrajectory or std_msgs/Float64MultiArray message types. This is configured in a yaml file (see config/ur_simulated_config.yaml for an example). Most robots that use ros_control will use the Float64MultiArray type. Some UR robots using older driver versions can require the JointTrajectory message type.

So could it be a possible way to send trajectory_msgs/JointTrajectory messages to /effort_joint_trajectory_controller/command?

Thanks a lot!

[DavidPL1]

Note that /controller_manager/load_controller only loads the controller without starting it. To start it, you additionally need to switch the effort_joint_trajectory_controller — which is started by default — with the joint_velocity_example_controller by running

rosservice call /controller_manager/switch_controller "start_controllers: ['joint_velocity_example_controller']
stop_controllers: ['effort_joint_trajectory_controller']
strictness: 0
start_asap: false
timeout: 0.0"

But that still won't do what you want to achieve: The joint_velocity_example_controller is only an example on how to perform velocity control with the panda and has a hardcoded trajectory in its update function right here:

https://github.com/frankaemika/franka_ros/blob/7a4fcdb6c0d47cea81c1ac7960f30ed8bf85b5fe/franka_example_controllers/src/joint_velocity_example_controller.cpp#L82-L103

If the controller started successfully, you should see some periodical movement (that btw. is currently broken, because the franka_gazebo noetic-devel and my port to mujoco contain a bug that does not apply the velocity commands, and I'll fix that right after finishing this comment). But since the controller is not listening to any external command, you are not able to do anything meaningful with it.

You could have a look at the effort_controllers/joint_velocity_controller and modify the example_velocity_controller accordingly to listen to a velocity command. Building the controller in your workspace, uploading the controller definition to the parameter server and then using the controller spawner node or the contoller_manager/load_controller service should then provide you with a command topic accepting velocity commands which get processed by the controller and applied in our simulation.

[DavidPL1]

I'm currently uploading a pre-release version 2.2 where the velocity control issue of the hardware interface is fixed. As an additional tip: while testing different controllers rqt_controller_manager is a very convenient tool

[Director-of-G]

You could have a look at the effort_controllers/joint_velocity_controller and modify the example_velocity_controller accordingly to listen to a velocity command. Building the controller in your workspace, uploading the controller definition to the parameter server and then using the controller spawner node or the contoller_manager/load_controller service should then provide you with a command topic accepting velocity commands which get processed by the controller and applied in our simulation.

Thanks for your reply. Following your instructions, we tried the following steps.

1. We created a ROS package named "franka_mujoco_controllers", which was copied from "franka_example_controllers";
2. We created a controller named "joint_velocity_controller" under namespace "franka_mujoco_controllers", which was modified from joint_velocity_example_controller. We only modified the names and paths.
3. We modified the "package.xml ", "franka_mujoco_controllers_plugin.xml" and "franka_mujoco_controllers.yaml" correspondingly;
4. We ran the server docker with --net=host, and loaded the controller definition "franka_mujoco_controllers.yaml" to parameter server;
5. We tried to load and start our controller in rqt_controller_manager, but failed. We got the error message from the running docker [ERROR] [1680579987.328417875] [ros.controller_manager] [/mujoco_server]: Could not load controller 'joint_velocity_controller' because controller type 'franka_mujoco_controllers/JointVelocityController' does not exist. [ERROR] [1680579987.328456363] [ros.controller_manager] [/mujoco_server]: Use 'rosservice call controller_manager/list_controller_types' to get the available types [ERROR] [1680579987.329389999] [ros.controller_manager] [/mujoco_server]: Could not start controller with name 'joint_velocity_controller' because no controller with this name exists;
6. We tried rosservice call controller_manager/list_controller_types but our controller type 'franka_mujoco_controllers/JointVelocityController' did not appear. We also tried rosrun controller_manager controller_manager reload-libraries, but our controller type still did not appear;

What's wrong with our process? We doubt whether the controller_manager only supports controllers defined in the server docker. Thanks a lot!

[DavidPL1]

I've tried it myself and it seems that the controller manager cannot access the new controller, because it is not located in its workspace.

I have a suggestion how we can solve this problem: If you are willing to make the custom controller publicly available, I've created a repository where you can add it as a subdirectory with a pull request. I can then add this repo to the build workspace in the server container and all participants will be able to use the controller in the challenge.

[DavidPL1]

I am sorry, apparently the upload of the 2.2-pre version last week was not successful. The current 2.2-pre version also includes this fix.

Are you still interested in a solution to this issue? What do you think about my proposed solution?

[Director-of-G]

Thanks for your help, we think the proposed solution makes sense. We rely on MoveIt for control for the time being, but custom controllers might be needed later. If it is the case, we'd like to do as you suggested.

I have a suggestion how we can solve this problem: If you are willing to make the custom controller publicly available, I've created a repository where you can add it as a subdirectory with a pull request. I can then add this repo to the build workspace in the server container and all participants will be able to use the controller in the challenge.