Advice on Motoman MH180

[Patrick Beeson]

I am working a new project that will be using a Motoman MH180.  This uses a DX200 controller, but to my knowledge, no one has used a Motoman that size of an MH180 with ROS before.  So, this is just a high level request for any non-documented advice by anyone that has used the Motoman ROS driver before.

Because this robot lives at a "traditional" integrator in Michigan, I can't really run the thing before I help those guys create a Ubuntu machine, install ROS-I, and get our software built.  So reports of any "funnies" that people know of when using this controller are welcome, as they won't know on first testing on a ROS-based system whether things look right or wrong.

Also, we will eventually be contributing the URDF, models, and SRDF back to ROS-I.  However, we want to get things correct first.  Specifically, we are finding a few weird things: 1) The zero encoder counts for the robot, which is the "Home" position is actually 0,+90,990,0,0,0; 2) The actual joint limits achievable by the robot are different from the Spec sheet joint angles (mainly for 1 pitch joint); 3) The velocity values are provided on the spec sheet, but I don't know how much to trust them given that the joint limits weren't correct; 4) Acceleration values are completely unknown (and it is unclear how to get these without experiments to find noisy estimates).

[G.A. vd. Hoorn - 3ME]

On 12-7-2016 15:58, Patrick Beeson wrote:
> I am working a new project that will be using a Motoman MH180. This uses a
> DX200 controller, but to my knowledge, no one has used a Motoman that size
> of an MH180 with ROS before. So, this is just a high level request for any
> non-documented advice by anyone that has used the Motoman ROS driver before.

I'm not sure which model it is exactly, but the Motoman that Kinema is
using in their promotional videos [1] seems to be a similar one, and I'm
almost sure they are using motoman_driver with it.

Personally I have recent experience with an SIA20 with an FS100.

> Because this robot lives at a "traditional" integrator in Michigan, I can't
> really run the thing before I help those guys create a Ubuntu machine,
> install ROS-I, and get our software built. So reports of any "funnies"
> that people know of when using this controller are welcome, as they won't
> know on first testing on a ROS-based system whether things look right or
> wrong.

It's important to know whether the controller is setup with multiple
motion groups. The ROS side, so not the motoros application, currently
doesn't work reliably / at all with > 1 or < 4 groups. See the issue
tracker [2] for some of these.

Another gotcha is the check the driver does on 'traj_start_state ==
current_state': because it uses relative motion, it's important the two
match. But depending on the pose of the robot, gravity might cause some
of the links (the 4th fi on your MH 180) to drop a little when
disengaging the breaks, leading to perfectly valid trajectories being
rejected. There is a PR [3] to increase the 'pulse threshold' exactly
because of this, but there might be other ways to deal with it that
might be preferable over just relaxing the condition (as it also
increases the possibility to deviate from the trajectory). In the APC
setup the work-around was to manually enable the servos (even in remote
mode).

I'll post some more issues on the tracker soon, which colleagues of mine
discovered while working on the Delft APC system. Most were also
worked-around / resolved. They should really only affect you if the
controller has multiple groups though.

Other than that we've found the driver to have very good performance,
and to be rather stable. Provided you have good quality trajectories
(ie: timing, positions, velocities and accelerations nice and smooth),
the robot will execute them faithfully.

Support from Motoman has also been great.

> Also, we will eventually be contributing the URDF, models, and SRDF back to
> ROS-I. However, we want to get things correct first. Specifically, we are
> finding a few weird things: 1) The zero encoder counts for the robot, which
> is the "Home" position is actually 0,+90,990,0,0,0; 2) The actual joint
> limits achievable by the robot are different from the Spec sheet joint
> angles (mainly for 1 pitch joint); 3) The velocity values are provided on
> the spec sheet, but I don't know how much to trust them given that the
> joint limits weren't correct; 4) Acceleration values are completely unknown
> (and it is unclear how to get these without experiments to find noisy
> estimates).

re: home position: are you worried that the 'zero position' of your urdf
won't correspond to the zero of the robot? What does the robot report
(joint angles) when it's at its zero? In any case: make the urdf for the
as-specced zero position. If the robot really reports non-zero angles
for it's home/zero, the ROS side should reflect that.

re: limits different from spec sheet: it would be preferable to create a
urdf based on the limits in the spec sheet. Then either use
config/joint_limits.yaml in your moveit config to override those, or
make a site-local change to the source of the package and use that in an
overlay.

The joint_limits.yaml approach might not be enough though, as not all
code-paths (in MoveIt) actually seem to use those values (but I can't
recall where I encountered/read that).

re: velocities: we typically stay with what the spec sheet says, as we
have no other information. I'd do that in this case as well. If your
specific robot can't actually reach those, the trajectory execution
monitor will quickly start interfering (aborting execution), which will
be a hint that something is up.

re: accelerations: that is a 'cross-vendor' problem. Afaik, none of the
moveit configs we have in ros-i contain those numbers, or at least not
the actual values. If you don't know, either leave them out
('has_acceleration_limits: false'), or guestimate some values (the
MoveIt Setup Assistant used to configure 1/5th max joint velocity for
this, fi). This is only a problem for the MoveIt configuration though.


Gijs

[1] http://www.kinemasystems.com
[2] https://github.com/ros-industrial/motoman/issues
[3] https://github.com/ros-industrial/motoman/pull/69

[Patrick Beeson]

Thanks Gijs, you are always a wealth of knowledge.

1) We only have 1 group, so that's good.
2) Not worried aobut the home configuration being non-zero, it's just weird that encoder==0 doesn't mean angle==0.
3) Not using MoveIt!, but using our Craftsman planning/control/Affordance Template framework.  We could easily add in soft limits, but these seem to be actual limits of the motoman robot that are 'drastically' different from the spec sheet.
4) Again, not using MoveIt!, so my software can also handle not having acceleration values.  But this is a time sensitive manufacturing cell, where speed is of the utmost importance, so I can't throttle speed to make up for unknown accelerations.  I need the robot to be moving at max vel and accelerations at all time (unless it stops to do vision).  I'll ping the Motoman support listed on the ROS-I pages (Assuming there is one).

[G.A. vd. Hoorn - 3ME]

On 12-7-2016 17:51, Patrick Beeson wrote:
> Thanks Gijs, you are always a wealth of knowledge.
>
> 1) We only have 1 group, so that's good.
> 2) Not worried aobut the home configuration being non-zero, it's just weird
> that encoder==0 doesn't mean angle==0.

It's not too uncommon for industrial robots actually, in my experience.

> 3) Not using MoveIt!, but using our Craftsman planning/control/Affordance
> Template framework. We could easily add in soft limits, but these seem to
> be actual limits of the motoman robot that are 'drastically' different from
> the spec sheet.

If you want to make sure 'everything' in your ROS node graph is using
the same limits, it'd probably be easiest to make a site-local overlay
workspace with the limits as configured on the controller in your urdf.

> 4) Again, not using MoveIt!, so my software can also handle not having
> acceleration values. But this is a time sensitive manufacturing cell,
> where speed is of the utmost importance, so I can't throttle speed to make
> up for unknown accelerations. I need the robot to be moving at max vel and
> accelerations at all time (unless it stops to do vision). I'll ping the
> Motoman support listed on the ROS-I pages (Assuming there is one).

You could see whether Motoman would be willing to provide you with the
values under NDA. I've seen other vendors do that. Not sure about
commercial applications though.

They're also sure to be somewhere in the controller, but I wouldn't know
how to get those out of a Motoman controller.

re: support listed on ros-i pages: I think they'll refer you to this
list ;).


Gijs

[Patrick Beeson]

Can anyone explain the difference between version0:= true and false?  Looks like one uses the industrial_robot_client  JointTrajectory Action server and the other uses the one in the motoman_driver repo.  I'm not sure how these differ, nor even how they differ from the default ROS JTFA actionlib.

--
You received this message because you are subscribed to a topic in the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swri-ros-pkg-dev/UMUZv91JFiA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrick Beeson]

Gijs,

Do you happen to know what happens if you send a JointTrajectory with more than just the 6 (or 7) joints that Motoman would expect?  For instance a JointTrajectory with joint_s, joint_l,...,joint_t, gripper_0 ?   If the motoman driver can handle this without faulting (presumably ignoring joints not in it's expected list) (again I'm not within a thousand miles of the robot for a while) then that would be useful, because I can just use the industrial-robot-client actionlib to handle everything between my execution layer and the hardware.  Otherwise, I'll need to use industrial-robot-client (and thus the simulation) for the arm only, and write more code to handle/simulate gripper motion.

Thanks

[ted miller]

Patrick,

> Velocity and acceleration limits.

The speed limits for each axis are publicly posted on the robot datasheet here: http://www.motoman.com/datasheets/MH180.pdf 

These values can also be obtained programmatically at runtime in the MotoROS driver for a more arm-agnostic solution. (The MotoPlus SDK is required to edit/compile the MotoROS code)

However, the acceleration limits are much more complex.  It varies greatly depending on many factors such as reach, tooling, payload, type of motion, etc... The acceleration values used by the DX200 motion planner cannot be extracted from the controller.

Instead of using fixed limits, we publish the maximum torque and inertia on the datasheet linked above.  You should use the values to calculate optimal acceleration for your application and prevent premature wear/tear of your gears.  You could also potentially modify the MotoROS code to monitor the feedback torque of each axis in real time.

> Trajectory with extra joint data

The JointTrajectory packet is a fixed-sized packet with an array for up to 10 axes.  In the MotoROS driver, the extra array elements will be ignored.  It's safe to populate those fields with additional data.

Please note that there is also a motoman-specific message that is supported by the robot driver to control basic I/O.  This is useful for basic digital gripper control.  (requires custom changes to your code on the PC side)

https://github.com/ros-industrial/motoman/blob/jade-devel/motoman_driver/MotoPlus/SimpleMessage.h#L58-L61 

On a different note, I have been providing support to our team in Michigan on the robot setup.  I can tell you with confidence that the robot driver is properly installed/configured with the latest version that is posted on Github.  So, no worries there.

-Ted

Yaskawa Motoman

[Patrick Beeson]

Does anyone know if the Motoman driver is smart enough to scale JointTrajectory waypoint times as needed if they request an unachievable (in terms of velocity) motion?

The issue I'm worried about is sending a joint trajectory that requires accelerations that the robot cannot achieve and thus we might see "choppy" or undesired (corner cutting) motion. I have a time sensitive manufacturing domain where the robot needs to be running as fast as possible, but it will be doing some straight line Cartesian motions, which require a lot of waypoints with lots of changing velocities (thus lots of coordinated max accelerations across joints).

I added in some idealized max accelerations to my system, which pads out times appropriately to make sure velocities at each segment can be achieved. But I can't guarantee the load/configuration will always be able to meet these values.

If the Motoman driver just handles this, it will save me some headache. Again, I only ask this because I'm programming for a robot that I do not have in my possession, which has been a tricky proposition.

Thanks
Patrick

[Edwards, Shaun M.]

​Patrick,

There may have been some improvements to the driver that I don't know about, but my understanding is the driver expects the trajectory to be within the limits of the system.  If a trajectory is outside the limits, then a fault (probably due to a control error) will result.  

-Shaun

---

From: Patrick Beeson <bees...@gmail.com>
Sent: Friday, July 22, 2016 7:19 PM
To: swri-ros...@googlegroups.com
Cc: Edwards, Shaun M.
Subject: Re: [ROS-Industrial] Advice on Motoman MH180

 

[ted miller]

The Motoman driver will not scale your input.

If you exceed maximum velocity, you will get an "Excessive Segment" alarm on the robot controller.  Currently, this would need to be reset on the pendant.  (The reset process could be improved in the future to be programmatic)

If you exceed maximum accel (over torque the motors), you could potentially trigger a "Collision Detect" or a "Servo Tracking Error" alarm.  Even if your accel is not severe enough to trigger an alarm, you can cause premature wear/tear on your drives which will affect the longevity of your robot.  Please ensure that you are staying within the rated values of the arm.

-Ted

Yaskawa Motoman

To unsubscribe from this group and all its topics, send an email to swri-ros-pkg-...@googlegroups.com.