YRC1000u starts moving after driver shutdown

[tall1]

I'm running ROS 1 and MoveIt to control the HC10DTP with YRC1000micro.
If i call the service /robot_enable and then shut down ROS - the robot keeps moving to an undefined position.

I tried solving this by calling
moveit_commander.os._exit(0)
after receiving a signal.SIGINT but this did not work.

Any ideas on how to stop the robot from moving after I shut down ROS?

I also thought of changing the robot to teach mode (via I/O) before shutdown which will probably prevent this, but this is just a work-around.

[ted-miller]

My recommendation would be to terminate the motion_streaming_interface node and/or call the /robot_disable service.

[tall1]

If I do a motion with moveit and then call /robot_disable, I get the same result - the robot keeps moving to an undefined position.

Edit: I only need to call /robot_enable to get this. I don't even need to do a motion.

[EricMarcil]

FYI, the MotoRos driver has an internal motion buffering and continues to process motion up to the last position transmitted in the ROS_MSG_MOTO_MOTION_CTRL message sent. So if you are in the middle of transmitting a trajectory and them close ROS or loose connection, the motion may continue for a few seconds until it reaches the last transmitted target position. Unless you explicitely tell it to stop as per Ted indication above.

[tall1]

I always let the robot finish the trajectory and then kill ROS or call /robot_disable. Still it makes unwanted movement after.

[gavanderhoorn]

If i call the service /robot_enable and then shut down ROS - the robot keeps moving to an undefined position.

Could you clarify what you mean exactly by this?

Is this after having submitted a trajectory goal, or even without one?

It could be malfunctioning, but there are various places where nodes shutting down and/or motion-related classes being dtor-ed should abort any ongoing motion.

Here fi:

motoman/motoman_driver/src/joint_trajectory_streamer.cpp

Lines 124 to 131 in 63e6242

	MotomanJointTrajectoryStreamer::~MotomanJointTrajectoryStreamer()
	{
	// SmplMsgConnection is not thread safe, so lock first
	// NOTE: motion_ctrl_ uses the SmplMsgConnection here
	const std::lock_guard<std::mutex> lock{smpl_msg_conx_mutex_};
	// TODO( ): Find better place to call StopTrajMode
	motion_ctrl_.setTrajMode(false); // release TrajMode, so INFORM jobs can run
	}

setTrajMode(false) should be equivalent to the /robot_disable service @ted-miller mentions.

[gavanderhoorn]

@tall1: if your robot is completely stopped, you start the driver, you don't send any action goal (ie: you don't move the robot using MoveIt or in any other way), then shut down the driver, does it also start moving after motoman_driver has shut down?

Or does it only do that if you've moved the robot at least once between starting and stopping motoman_driver?

[tall1]

Or does it only do that if you've moved the robot at least once between starting and stopping motoman_driver?

It does that only if I move the robot at least once after starting the motoman_driver.

Edit: It starts moving even without doing one movement with the robot. It is enough to only call /robot_enable

[gavanderhoorn]

So to conclude, the following sequence results in motion towards some unknown destination point:

1. robot fully stopped, controller running nothing (no INFORM job active)
2. start motoman_driver using the appropriate .launch file
3. call /robot_enable
4. don't send any action goals, immediately call /robot_disable

Can you confirm that at this point your robot starts moving?

I would agree with @ted-miller and would suggest to record a video of the robot showing it while you call /robot_enable, it standing still, and then while calling /robot_disable.

In addition, capture the network traffic between your ROS PC (the one running motoman_driver) and the YRC1000u.

[tall1]

Can you confirm that at this point your robot starts moving?

Yes.

Below I replied to @EricMarcil and recorded two videos + uploaded a WireShark recording of the communication between the robot and the PC.

[EricMarcil]

The only thing I can think of is that when MotoRos terminates, the INIT_ROS resumes executions, so if you have motions in the job or INIT_ROS was called from another job that has motion, then that motion would get executed.

Can you give a bit more information about the motion occuring afterward...
Does the robot seem to go to a specific position?
Does it move in a specific direction?
How much doesn't it move?

Could be that HC force sensor are not properly calibrated and the change of mode is activation the anti-clamping or avoidance function..?

[gavanderhoorn]

I thought you meant joint degrees at first..

I do. Or radians.

I believe you assume I'm talking about a Cartesian coordinate?

[tall1]

I do. Or radians.

I call the /robot_disable from the Work Home position - all of the joints are positioned at 0.

I believe you assume I'm talking about a Cartesian coordinate?

Yes. That actually might be more reasonable because the robot tries to move to end effector somewhere near the base_link. That's where the all-zero Cartesian coordinate is, am I wrong?

[ted-miller]

the robot tries to move to end effector somewhere near the base_link. That's where the all-zero Cartesian coordinate is, am I wrong?

The origin of robot-frame is located in the middle of the S/L joint. However, in this case, the robot appears to be returning to the home position, which is zero pulse-counts on each link.

would it matter if that Ros_Controller_SetIOState(..) failed?

That would leave the Inform job in a motion-ready state. However, I can't figure out how the internal motion queue got populated/incremented.

---

@tall1:

• Has your MotoROS.out file been modified in any way using the MotoPlus SDK?
• Can you post a photo of the INIT_ROS job on your teach pendant?
• Please set robot parameter S2C1119=2 and reboot the controller. Then open a Telnet connection to the robot. The username and password are both MOTOMANrobot. Then please repeat the issue. I'd like to see any output that prints to the telnet console.

[tall1]

Has your MotoROS.out file been modified in any way using the MotoPlus SDK?

Not as far as I know. We installed MotoROS exactly as the manual said. No other modifications have been made.

Can you post a photo of the INIT_ROS job on your teach pendant?

Then open a Telnet connection to the robot. The username and password are both MOTOMANrobot

Can you please instruct or reference me?

[ted-miller]

Then open a Telnet connection to the robot. The username and password are both MOTOMANrobot

Can you please instruct or reference me?

No need. The problem is definitely the JointMove commands in the job. These are what is generating the motion.

Please replace the job with the file here: https://github.com/ros-industrial/motoman/tree/kinetic-devel/motoman_driver/Inform/DX200%2C%20FS100%2C%20YRC1000/single_arm

[EricMarcil]

@tall1 Can you also report what the job on the pendant is displaying when this is occurring.
Are you still on the WAIT instruction while the robot is moving toward the home position after the /robot_disable?

[tall1]

When I call /robot_disable the job changes from WAIT to JointMove

[ted-miller]

It sounds like that's likely the issue. The JointMove command should not be in your job. The /robot_disable service causes the cursor to move off of the WAIT command and execute the next line.

Please replace the job with the file here: https://github.com/ros-industrial/motoman/tree/kinetic-devel/motoman_driver/Inform/DX200%2C%20FS100%2C%20YRC1000/single_arm

[gavanderhoorn]

@tall1: could you clarify where you found the job you show in the screenshot?

As mentioned by @ted-miller, that's definitely not standard.

[tall1]

For some reason I'm getting an error:

The .DAT file transfers without a problem though.
I tried doing this through the classic interface and I get the same issue.
It doesn't seem to notice the NOP or END tags.

[gavanderhoorn]

Could be ERROR 3200: NOP or END instruction not found.

[EricMarcil]

That usually occurs when you get a job (which is a text file) with the Linux standard of having only CR character at then end of lines, instead of the Windows standard CR/LF characters.

[tall1]

Please try downloading this job. Just unzip and paste on your USB drive without opening it in a text editor.
INIT_ROS.zip

It worked!
The robot does not move after calling /robot_disable.

Thanks!