You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has the debug log, along with output from a few command line service calls. The calling code calls start_traj_mode and waits for the result, sleeps for a few seconds (disabled in these runs), then tries to send motion.
The first run will usually be fine. If the drives are in power saving and there isn't a long sleep after the start_traj_mode call, it will fail. Is start_traj_mode supposed to wait until the servos are ready?
This code was quickly changed from using the ros1 driver through the bridge to native ros2. I'm going to try modifying the code to check robot_status.motion_possible.
I did notice while echoing the topic in a terminal with the servos sleeping, after calling start_traj_mode the drives_powered and motion_possible flags will both change to 1, then motion_possible will briefly change to 0 before changing back to 1.
One other error when enabling without resetting the error:
[2023-07-13 11:47:09.181057] [192.168.1.20:65486]: Ros_MotionControl_StartMotionMode: enter
[2023-07-13 11:47:10.423340] [192.168.1.20:65486]: Robot job is ready for ROS commands.
[2023-07-13 11:47:10.480666] [192.168.1.20:65486]: Ros_MotionControl_StartMotionMode: exit
[2023-07-13 11:47:10.480771] [192.168.1.20:65486]: Ros_ServiceStartTrajMode_Trigger: INFORM job is not on a WAIT command. Check the format of INIT_ROS (109)
[2023-07-13 11:47:10.538726] [192.168.1.20:65486]: Robot job is ready for ROS commands.
mpExRcsIncrementMove returned -1 (Not executing WAIT instruction)
...
Ros_ServiceStartTrajMode_Trigger: There was an error with the internal motion API (112)
Is start_traj_mode supposed to wait until the servos are ready?
The service should not return a response until the startup routine is complete (or has an error). I don't know if the client API you're using has a timeout in it.
Cpp, the usual async_send_request, waiting for the future without a timeout, then getting the result.
Ros_ServiceStartTrajMode_Trigger: INFORM job is not on a WAIT command. Check the format of INIT_ROS (109)
When I get this error it looks like the motion_possible flag is set, and in_error is 0. When I try to enable the robot again, in_error will change to 1 and I'll get the less friendly mpExRcs... error.
Issue encountered on DX200.
robot_sleep_error_clean.txt
This has the debug log, along with output from a few command line service calls. The calling code calls start_traj_mode and waits for the result, sleeps for a few seconds (disabled in these runs), then tries to send motion.
The first run will usually be fine. If the drives are in power saving and there isn't a long sleep after the start_traj_mode call, it will fail. Is start_traj_mode supposed to wait until the servos are ready?
This code was quickly changed from using the ros1 driver through the bridge to native ros2. I'm going to try modifying the code to check robot_status.motion_possible.
I did notice while echoing the topic in a terminal with the servos sleeping, after calling start_traj_mode the drives_powered and motion_possible flags will both change to 1, then motion_possible will briefly change to 0 before changing back to 1.
One other error when enabling without resetting the error:
Originally posted by @smith-doug in #49 (comment)
The text was updated successfully, but these errors were encountered: