Error with new version image

[renyu2016]

Hi, I downloaded the new release version of the server image(docker.assembly_server-v2.0) and deployed it on my local computer. But when I run the command: docker run --rm -it s4dx/assembly_server_v2 on the terminal, something is wrong. The output and the context in the log file are attached.

I am not sure whether this is a bug or just there are some steps I missed. Looking forward to your reply. bug_v2.txt

[DavidPL1]

You have to provide the task rosparam (either screwing or plugging) then it should work. I will add an error message if it's missing for more clarity.

Edit: For example, running docker run --rm -it s4dx/assembly_server_v2 task:=screwing in your case will start the screwing task

[renyu2016]

You have to provide the task rosparam (either screwing or plugging) then it should work. I will add an error message if it's missing for more clarity.

Edit: For example, running docker run --rm -it s4dx/assembly_server_v2 task:=screwing in your case will start the screwing task

I tried the command docker run --rm -it s4dx/assembly_server_v2 task:=screwing but the error is still existing. More specifically, when I specific headless:=true, i.e., docker run --rm -it s4dx/assembly_server_v2 task:=screwing headless:=true, The follow error will happen:

[ INFO] [1679926348.943960644] [ros.mujoco_ros_control] [/mujoco_server]: Loaded mujoco_ros_control Traceback (most recent call last): File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_base.py", line 569, in connect self.read_header() File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_base.py", line 664, in read_header self._validate_header(read_ros_handshake_header(sock, self.read_buff, self.protocol.buff_size)) File "/opt/ros/noetic/lib/python3/dist-packages/rosgraph/network.py", line 357, in read_ros_handshake_header d = sock.recv(buff_size) ConnectionResetError: [Errno 104] Connection reset by peer

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_service.py", line 509, in call transport.connect(dest_addr, dest_port, service_uri) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_base.py", line 596, in connect raise TransportInitError(str(e)) #re-raise i/o error rospy.exceptions.TransportInitError: [Errno 104] Connection reset by peer

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/home/assembly_server/lib/assembly_manager/assembly_manager", line 5, in main() File "", line 34, in main File "", line 554, in start File "", line 448, in wait_for_sim File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_service.py", line 442, in call return self.call(*args, **kwds) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/impl/tcpros_service.py", line 512, in call raise ServiceException("unable to connect to service: %s"%e) rospy.service.ServiceException: unable to connect to service: [Errno 104] Connection reset by peer [move_group-7] killing on exit [virtual_joint_broadcaster_0-6] killing on exit [joint_state_publisher-5] killing on exit [robot_state_publisher-4] killing on exit [panda_controller_spawner-3] killing on exit [panda_gripper_spawner-2] killing on exit [mujoco_server-1] killing on exit Loading 'move_group/ApplyPlanningSceneService'... Loading 'move_group/ClearOctomapService'... Loading 'move_group/MoveGroupCartesianPathService'... Loading 'move_group/MoveGroupExecuteTrajectoryAction'... Loading 'move_group/MoveGroupGetPlanningSceneService'... Loading 'move_group/MoveGroupKinematicsService'... Loading 'move_group/MoveGroupMoveAction'... Loading 'move_group/MoveGroupPickPlaceAction'... Loading 'move_group/MoveGroupPlanService'... Loading 'move_group/MoveGroupQueryPlannersService'... Loading 'move_group/MoveGroupStateValidationService'... Loading 'pilz_industrial_motion_planner/MoveGroupSequenceAction'... Loading 'pilz_industrial_motion_planner/MoveGroupSequenceService'...

You can start planning now!

Traceback (most recent call last): File "/opt/ros/noetic/lib/controller_manager/spawner", line 219, in if name == 'main': main() File "/opt/ros/noetic/lib/controller_manager/spawner", line 123, in main rospy.sleep(0.2) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 165, in sleep raise rospy.exceptions.ROSInterruptException("ROS shutdown request") rospy.exceptions.ROSInterruptException: ROS shutdown request Traceback (most recent call last): File "/opt/ros/noetic/lib/controller_manager/spawner", line 219, in if name == 'main': main() File "/opt/ros/noetic/lib/controller_manager/spawner", line 123, in main rospy.sleep(0.2) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 165, in sleep raise rospy.exceptions.ROSInterruptException("ROS shutdown request") rospy.exceptions.ROSInterruptException: ROS shutdown request [assembly_manager-2] process has died [pid 61, exit code 1, cmd /home/assembly_server/lib/assembly_manager/assembly_manager __name:=assembly_manager __log:=/root/.ros/log/6647f0a6-cca9-11ed-94ad-0242ac110004/assembly_manager-2.log]. log file: /root/.ros/log/6647f0a6-cca9-11ed-94ad-0242ac110004/assembly_manager-2*.log

The complete terminal output is attached in the file bug_v2_headless.txt

[renyu2016]

You have to provide the task rosparam (either screwing or plugging) then it should work. I will add an error message if it's missing for more clarity.

Edit: For example, running docker run --rm -it s4dx/assembly_server_v2 task:=screwing in your case will start the screwing task

When I don't specific headless:=true, i.e., docker run --rm -it s4dx/assembly_server_v2 task:=screwing, the terminal will stop and keep waiting at the output

[ WARN] [1679926813.754323766] [ros.mujoco_ros.mujoco_env] [/mujoco_server]: Model offscreen resolution too small for configured cameras, updating offscreen resolution to fit cam config ... (1080x720)

the complete terminal output is attached in the file bug_v2_wo_headless.txt

[DavidPL1]

When I don't specific headless:=true, i.e., docker run --rm -it s4dx/assembly_server_v2 task:=screwing, the terminal will stop and keep waiting at the output [ WARN] [1679926813.754323766] [ros.mujoco_ros.mujoco_env] [/mujoco_server]: Model offscreen resolution too small for configured cameras, updating offscreen resolution to fit cam config ... (1080x720)

This is expected behavior. As described here, you need to call the /user_ready service to start the task run.

As for the headless:=true case: this is very strange, I'm looking into it right now. For the time being I'd recommend using headless:=false (which is the default if you provide at least one other argument). It should slightly increase resource usage, but otherwise behave exactly as the headless case.

[DavidPL1]

I managed to fix the error. Version 2.1 of the image is currently being uploaded to the cloud. Could you please verify that headless:=true now also works for you?

Also, I was wrong about having to specify the task parameter. I missed that the launchfile has the default value set to screwing.

[renyu2016]

Thanks! I will verify the image V2.1 later. Now, after executing rospy.wait_for_service('user_ready') user_ready = rospy.ServiceProxy('user_ready', Trigger) user_ready(TriggerRequest()) I have successfully communicated with sever V2.0. I could read RGB-D images from cameras and move Franka arm as I planned. But I met some other problems.

1. I indeed find the topic /cameras/workspace_cam(2)/camera_info in the rostopic list, but I can't get any value from the following code q_name = '/cameras/' + 'workspace_cam'+ '/camera_info' cam_info_msg = rospy.wait_for_message(q_name, sensor_msgs.msg.CameraInfo) the program will keep waiting in this line. I also try to listen topic with rostopic echo /cameras/workspace_cam/camera_info, but i cannot get anything and the terminal tells me

   root@bb081ac5fa88:/home# rostopic echo /cameras/workspace_cam/camera_info WARNING: no messages received and simulated time is active. Is /clock being published? (But I can successfully listen the value of the /cameras/workspace_cam/rgb and depth using rostopic echo)

How should I get the values from this topic?

2. For the task:=screwing, whatever I specify the difficulty_level:=1, 2, or 3, the loaded scene seems always to be the difficulty_level=1 scene. Just like the following picture:

Furthermore, I find when I start server with difficulty_level:=3, the terminal output

PARAMETERS

• /assembly_manager/difficulty_level: 3
• /assembly_manager/eval_mode: False
• /assembly_manager/headless: False
• /assembly_manager/save_results_path:
• /assembly_manager/seed: -1
• /assembly_manager/task: screwing
• /assembly_manager/verbose: False
  • /rosdistro: noetic
• /rosversion: 1.15.15

But when I read the difficulty_level with code difficulty_level = rospy.get_param('/difficulty_level') I still got difficulty_level is 1.

[DavidPL1]

In the future please open separate issues for different problems, it's easier to track that way.

I indeed find the topic /cameras/workspace_cam(2)/camera_info in the rostopic list, but I can't get any value from the following code q_name = '/cameras/' + 'workspace_cam'+ '/camera_info' cam_info_msg = rospy.wait_for_message(q_name, sensor_msgs.msg.CameraInfo) the program will keep waiting in this line. I also try to listen topic with rostopic echo /cameras/workspace_cam/camera_info, but i cannot get anything and the terminal tells me

Camera info is published simultaneously with camera images, because camera parameters can be changed over time and ROS uses the timestamps to match camera info messages with the camera images. For efficiency reasons camera images are only rendered and published, if at least one subscriber to the image topic exists. Thus you have to subscribe to the corresponding image topic and receive at least one image in order for camera info to be available.

But when I read the difficulty_level with code difficulty_level = rospy.get_param('/difficulty_level') I still got difficulty_level is 1.

During refactoring, a bug was introduced that ignored the provided difficulty level and would always set it to 1. This has now been fixed. Thanks for reporting it.

As version 2.1 has not been officially released yet, I have replaced it in the cloud.

[renyu2016]

Got it!