search

Yaskawa-Global / motoros2

ROS 2 (rcl, rclc & micro-ROS) node for MotoPlus-compatible Yaskawa Motoman robot controllers
89 stars 14 forks source link

Support for FS100 controllers #227

Open gavanderhoorn opened 3 months ago

gavanderhoorn commented 3 months ago

This is for #19 (and a resubmit of #226 from a branch here on the main repository).

A draft currently, but first steps towards FS100 support.

gavanderhoorn commented 3 months ago

CI will fail as we currently have no release of M+ libmicroros for FS100.

We'll deal with that later.

Edit: and of course because of https://github.com/Yaskawa-Global/motoros2/pull/212#issuecomment-1963952062.

gavanderhoorn commented 3 months ago

@ted-miller: after I rebased this branch on main my FS100 now complains because the binary includes #212 and I can't seem to set the cycle mode to continuous.

There's only AUTO, CYCLE and STEP. If I set it to AUTO, SOUT#035 becomes high, but as soon as I switch the TP to Remote, cycle gets reset to CYCLE.

Any ideas?

gavanderhoorn commented 3 months ago

Something to decide: the current work-around/hack mentioned in https://github.com/Yaskawa-Global/motoros2/issues/19#issuecomment-1930072900 only works for Agents running on little-endian machines.

I expect that to be the typical setup for use with MotoROS2 (ie: amd64 based ROS PC running the Agent), but I could see someone trying to use an RPi or similar aarch64 or aarch32 platform to delegate the Agent to.

That would not work for the FS100.

Personally, I feel we could document this, but:

  1. the asymmetry with the other controllers is not nice (™)
  2. MotoROS1 had no such limitation
  3. it's likely such a note in our documentation will be overlooked, leading to users posting issues and/or opening discussions about their installation not working

Given the fact the FS100 is a legacy platform at this point this may all be acceptable, but we need to decide how we want to approach this.

ted-miller commented 3 months ago

There's only AUTO, CYCLE and STEP. If I set it to AUTO, SOUT#035 becomes high, but as soon as I switch the TP to Remote, cycle gets reset to CYCLE. Any ideas?

Go to Setup > Operate Cond. Then change the CYCLE SWITCH IN REMOTE MODE setting.

Given the fact the FS100 is a legacy platform at this point this may all be acceptable, but we need to decide how we want to approach this

I'm of this opinion. Just document the limitation and move on.

There will be a limited set of users using MR2 on FS100 and a much smaller set of those using a bigendian cpu.

ted-miller commented 3 months ago

@gavanderhoorn Beyond the potential endianness issue, what concerns do you have? Given the success of the previous testing, I'm not really sure why this is a 'draft' PR.

My biggest concern is that we haven't validated on a non-dummy controller. I'm going to try to scrounge up one of the old educational carts.

Now that the rebase is complete, I'm happy to test all topics/services again. Please provide a binary of the libmicroros. (I'll also validate the VS settings for building MR2.)

ted-miller commented 3 months ago

I've located an FS100 with an arm. It should be here tomorrow afternoon.

gavanderhoorn commented 3 months ago

It's partly a draft because I haven't actually moved anything, neither real hw nor virtual.

It also lacks documentation updates, and I still need to verify which parameters need to be set to which values.

ted-miller commented 3 months ago

I still need to verify which parameters need to be set to which values.

From my personal notes regarding the FS100:

S1D320 = 1 //Allow ".out" files to be loaded (I think this gets set with the MOTOMAN DRIVER option function)

I don't think that S2C1402 exists.

Everything else should be covered by our existing setup-instructions.

ted-miller commented 3 months ago

@gavanderhoorn Can you provide the latest libmicroros or .out? Or would you prefer I validate using <outdated_binary> ?

gavanderhoorn commented 3 months ago

Or would you prefer I validate using <outdated_binary> ?

that wouldn't work, as it has DUMMY_SERVO_MODE enabled.

I'll build a fresh alpha.

gavanderhoorn commented 3 months ago

@ted-miller: here you go: <outdated_binary>.

ted-miller commented 3 months ago

I'll do some more thorough testing next week. But doing a quick test, I was able to get the robot to move with the point-queue service.

Other quick notes:

gavanderhoorn commented 3 months ago

I'll do some more thorough testing next week. But doing a quick test, I was able to get the robot to move with the point-queue service.

:+1:

Other quick notes:

  • effort data in joint_states is garbage data

hm. Is this a known issue? I'm running FS4.00 here.

  • velocity fields in joint_states are always zero

Probably due to the M-register for velocity feedback not being supported on FS100? At least that's what logged on my controller when it boots up MotoROS2.

  • The feedback position is 'laggy'. If I jog the robot, the position immediately updates. But when I release the jogging button, the position coasts for about a second before coming to a stop. I see this same behavior on the pendant, so it's not MR2. But it is something different with the FS100.

I believe I've seen something similar, but wasn't sure whether it was caused by the fact I don't have any manipulator connected.

ted-miller commented 3 months ago

effort data in joint_states is garbage data

hm. Is this a known issue? I'm running FS4.00 here.

No. The M+ manual says the API should work. But I looked at MR1 code and see that Ros_CtrlGroup_GetTorque never actually gets called anywhere. So, I don't have any known examples of the API working on the FS100.

velocity fields in joint_states are always zero

Probably due to the M-register for velocity feedback not being supported on FS100? At least that's what logged on my controller when it boots up MotoROS2.

Yup. That'll do it.

image

I guess we need to convert Ros_CtrlGroup_GetFBServoSpeed to use mpSvsGetVelTrqFb. But that's assuming mpSvsGetVelTrqFb actually works... (It's what is being used for effort data.)

gavanderhoorn commented 3 months ago

I guess we need to convert Ros_CtrlGroup_GetFBServoSpeed to use mpSvsGetVelTrqFb. But that's assuming mpSvsGetVelTrqFb actually works... (It's what is being used for effort data.)

I believe we have an open issue on the internal tracker (#547) where in the end I commented:

According to yourself (here), M-registers are better ;)

I was confused by the comments in that issue as you also suggested changing to mpSvsGetVelTrqFb(..), but that was/is already used. At least in MotoROS1.

ted-miller commented 3 months ago

(Not sure if this note is a repost. I know I had something typed up, but I think I closed the window prematurely.)

I made a small app that just polls mpSvsGetVelTrqFb continuously.

For velocity: With servos off and the brakes engaged, I'm getting random +/- 1248 on one or more axes every few cycles. But while jogging, the numbers look reasonable.

For effort: I don't know what to think of the numbers being displayed. I need to do more testing. The pendant only displays percent of rated max torque, so I don't have a good correlation between this and Nm.

But it seems like there's a lot of fluctuation on multiple axes for even a very simple motion, such as jogging the S axis. Also, the resting-position seems unusual. If I jog S+ the value spikes. When motion is complete, the value settles around 15000. But then if I jog S- and stop, the value settles around -10000. I understand the sign inversion, but I don't get why the absolute value is significantly different.

I tested a motion with the FJT script. The motion worked, but the final position was outside of tolerance on both axes that I moved by 0.012 rad.

I'm wondering if this is related to the 'laggy' response I get when jogging.

In the error message about the trajectory being outside tolerance, the joint names were non-ascii characters.

https://github.com/Yaskawa-Global/motoros2/blob/7f95156533a90f5efa0a46dd7f00c74a32c439bd/src/ActionServer_FJT.c#L571-L573

This has me questioning if something is overflowing an array. Or perhaps this isn't working properly.

gavanderhoorn commented 3 months ago

Hm. Sounds like something isn't working.

re: velocities & torques: could this be rate-dependent?

gavanderhoorn commented 2 months ago

@ted-miller: I've added dd13f53bdbea0c4dc5d0aaf0005262c06e267237 which (im)ports the MotoROS1 version of Ros_CtrlGroup_GetFBServoSpeed(..) to use mpSvsGetVelTrqFb(..) instead of the M-registers.

gavanderhoorn commented 2 months ago

@ted-miller: I just remembered I haven't actually built this branch after I added d4fb2fd997832330b6a6d7b6c3914109946ecb4e.

gavanderhoorn commented 2 months ago

@ted-miller wrote:

In the error message about the trajectory being outside tolerance, the joint names were non-ascii characters.

https://github.com/Yaskawa-Global/motoros2/blob/7f95156533a90f5efa0a46dd7f00c74a32c439bd/src/ActionServer_FJT.c#L571-L573

Should that be feedback_FollowJointTrajectory.feedback.joint_names.data[axis].data? Technically feedback_FollowJointTrajectory.feedback.joint_names.data[axis] is a rosidl_runtime_c__String, not a const char*.

This has me questioning if something is overflowing an array. Or perhaps this isn't working properly.

Technically I believe we could use rosidl_runtime_c__String__copy(..) instead of 'abusing' _assign(..), but it wouldn't really make much difference IIUC.

ted-miller commented 2 months ago

I just remembered I haven't actually built this branch after I added https://github.com/Yaskawa-Global/motoros2/commit/d4fb2fd997832330b6a6d7b6c3914109946ecb4e.

I was able to build this yesterday. Though, I did have to shrink SIZEOF_BUFFER_FJT_GOAL yet again to make it load without 1020 [6]. (Admittedly, I didn't strip the binary after building and it was 300-400k larger than alpha50. So perhaps that would have made a difference.)

Also, there were a bunch of annoying warnings about an unneeded const identifier. I'm thinking that we should remove the -Wall from the compiler arguments for FS100. Presumably, any "important" warnings would also be raised by the DX/YRC compilers.

Should that be feedback_FollowJointTrajectory.feedback.joint_names.data[axis].data

Technically, yes. But since the string pointer is the first entry in that structure, it should be ok.

gavanderhoorn commented 2 months ago

Though, I did have to shrink SIZEOF_BUFFER_FJT_GOAL yet again to make it load without 1020 [6]. (Admittedly, I didn't strip the binary after building and it was 300-400k larger than alpha50. So perhaps that would have made a difference.)

that should indeed not really be needed.

I may be doing something 'different' when building it here. I'll take a look at my settings.

Also, there were a bunch of annoying warnings about an unneeded const identifier. I'm thinking that we should remove the -Wall from the compiler arguments for FS100. Presumably, any "important" warnings would also be raised by the DX/YRC compilers.

I don't remember anything about const modifier (I guess?), I do have warnings about return types, for which I added -Wno-return-type. But only for the FS100 builds.

Should that be feedback_FollowJointTrajectory.feedback.joint_names.data[axis].data

Technically, yes. But since the string pointer is the first entry in that structure, it should be ok.

technically, yes.

But after I changed that when working on #233, the issues with doubles and Ros_Debug_BroadcastMsg(..) stopped.

gavanderhoorn commented 1 month ago

@ted-miller: have you had any time to take a further look at this?

ted-miller commented 1 month ago

No I haven't. I'm definitely not going to be able to get to it until at least the end of the month.

Sanchitkedia commented 2 weeks ago

@gavanderhoorn I have a Yaskawa Motoman SIA20F with an FS100 controller and can try to run this on my end. Could you help me with the necessary files and instructions on how to get started?

gavanderhoorn commented 1 week ago

@Sanchitkedia: could you provide some more information about your FS100? The current minimal controller software version we support is 4.00 for instance, which is relatively new (for FS100s, that is).

gavanderhoorn commented 1 week ago

@ted-miller: I've drafted a prerelease version of M+ libmicroros for FS100 here: Yaskawa-Global/micro_ros_motoplus/releases.

Sanchitkedia commented 1 week ago

@Sanchitkedia: could you provide some more information about your FS100? The current minimal controller software version we support is 4.00 for instance, which is relatively new (for FS100s, that is).

My System is currently running on FS 3.28.00

ted-miller commented 1 week ago

I've drafted a prerelease version of M+ libmicroros for FS100 here

Does this contain anything new/changed since the April tests?

My System is currently running on FS 3.28.00

@Sanchitkedia I'll send a download link for new FS100 software to the email address in your github profile.

gavanderhoorn commented 1 week ago

I've drafted a prerelease version of M+ libmicroros for FS100 here

Does this contain anything new/changed since the April tests?

not necessarily. It's libmicroros for the FS100, so not a MotoROS2 binary.

I did make sure to include all the changes made to micro_ros_motoplus since we migrated to the new distribution approach.

This is also the version that -- together with some additional changes on the MotoROS2 side -- results in significantly smaller binaries.

gavanderhoorn commented 1 week ago

Rebased on top of main and added a temporary change to CI to get it to run with the draft M+ libmicroros release for FS100 mentioned in https://github.com/Yaskawa-Global/motoros2/pull/227#issuecomment-2187076126.

gavanderhoorn commented 3 days ago

@Sanchitkedia: have you been able to upgrade your FS100?

Sanchitkedia commented 3 days ago

@Sanchitkedia: have you been able to upgrade your FS100?

Not yet, but it should be done this week. I await the approval and go-ahead from others who use the robot.

Sanchitkedia commented 2 days ago

@gavanderhoorn @ted-miller Upgrade to version 4.00 was completed successfully. Can you please provide the next steps?

gavanderhoorn commented 2 days ago

@ted-miller wrote:

Other quick notes:

  • effort data in joint_states is garbage data

and:

In the error message about the trajectory being outside tolerance, the joint names were non-ascii characters.

just tested on FS100 again, and although I did not encounter the things you describe @ted-miller, I did notice some strings in the debug log contained non-ascii characters.

Specifically, in this line:

https://github.com/Yaskawa-Global/motoros2/blob/a1c9b5b7f9a9e0806dd67ba9f087701d4a821bd6/src/ServiceResetError.c#L126

response->message contained things like ELP, E=@ and EA`. Or at least I think it did, as that's what showed up on the PC running the debug client.

gavanderhoorn commented 1 day ago

Ok @Sanchitkedia.

[!CAUTION]
The binary made available here is an alpha, with all the caveats about quality, robustness, fitness for a particular purpose, etc that label implies.

Do not use this for anything else but testing, and be very careful when trying to run this on your FS100. Be especially careful when trying to execute motion.

Even if it doesn't immediately crash, it may run into issues later, so never leave your controller and/or robot running this alpha of MotoROS2 unsupervised. Make absolutely sure your robot is in a position where it can be used to test (ie: not integrated into any machines, encumbered by tight spaces or subject to specific motion constraints (such as narrow joint limits)), and make sure you can reach the emergency stop of your robot.

Having written that: this is the current alpha60 binary: 20240703_mr2_fs1_h_9.9.9-FS100-alpha60.zip.

Installation is similar to YRC1000 and DX200, but please be patient when installing the .out from USB: the FS100 can be very slow when copying the file and it can appear 'frozen'. Do not interfere and just wait for it to complete the installation (https://github.com/Yaskawa-Global/motoros2/issues/19#issuecomment-1997960174).

(note: we haven't yet updated the documentation, so you can't necessarily follow the instructions when it comes to configuring specific values for parameters. See also @ted-miller's https://github.com/Yaskawa-Global/motoros2/pull/227#issuecomment-2018801181)

Please document your installation experience, and log any and all errors and warnings -- whether on the pendant, a terminal or somewhere else.

Before installation, please make sure to have the debug log client running. This will let you (and us) capture all output MotoROS2 may produce while starting up and during execution and will help us diagnose any issues.

Finally: I don't expect this to (catastrophically) fail, but please keep your own safety, that of any of your colleagues (or fellow students) and of your equipment in mind while testing this.

Edit:

[!IMPORTANT]
The FS100 has less resources available than more modern controllers. This limits the maximum length of trajectories even further than for the YRC1000 and DX200. It's likely the point queuing mode is more useful with FS100 than the FollowJointTrajectoryAction server.