Getting ROS-I to work on Fanuc LR Mate 200iB 3L

[Lucas Chavez]

Hello, 

I am new to ROS Industrial, but I have used ROS Diamondback (back in 2011) for a mobile robot application.

I am now tasked with getting ROS Industrial to work on a 2003 Fanuc LR Mate 200iB 3L whose controller is a HandlingTool R-J3iB Mate running version M6.11-1A without an iPendant. Also, I don't have Roboguide. I am relying on Fanuc's WinOLPC, PC File Services, and FRRobotDemo. 

Here is my dog Pepper with the robot.  In a shameless attempt to use my dog to get more help :) 

I have been diving into the documentation, reading posts here, and on ROS answers. I have a two major concerns, before I go deeper I want to list them and ask for answers/tips/opinions/help:

Background Info: 

• I am running ROS Indigo on Ubuntu 14.04 (I know I will need to build ROS Industrial from source, I believe I just need to follow http://wiki.ros.org/fanuc_driver "Indigo compatibility")
  
• I got the karel code from the "hydro-devel" branch of ros-industrial/fanuc

1. Changing Karel code to work with v6.11-1A and no iPendant, also translating with WinOLPC. I want to eventually merge these changes into the github repo. Are these the type of changes the community wants? 

• Upgrading to v7 would be ideal. We have contacted Fanuc and they say my controller is not capable of being upgraded. 
• I had to change 4 files in order to get everything to get the Karel code to translate. Folder _github is fresh from github and _translated is what I had to do to get it to translate. See attached .txt documents:

diff -rw fanuc_driver_github/karel/libind_log.kl fanuc_driver_translated/karel/libind_log.kl > diff__libind_log.txt
diff -rw fanuc_driver_github/karel/libind_rs.kl fanuc_driver_translated/karel/libind_rs.kl > diff__libind_rs.txt
diff -rw fanuc_driver_github/karel/ros_relay.kl fanuc_driver_translated/karel/ros_relay.kl > diff__ros_relay.txt
diff -rw fanuc_driver_github/karel/ros_state.kl fanuc_driver_translated/karel/ros_state.kl > diff__ros_state.txt

• libind_log.kl : Had to remove color definitions because I don't have an iPendant. I should be able to check if variables were initiated and use control logic to do this better. 
• libind_rs.kl : Help! Had to remove the check which sees if the robot is moving. Made it so that the code thinks the robot is always moving. I believe because I am v6.11-1A I don't have the system variable $MOR_GRP[1].$ROB_MOVE. How else can I do this check? Is there a way to check what version I am running in the Karel code? 
• ros_relay.kl : 
• Had to change SHADOW to DRAM. This specifies what type of memory rrelay_cfg_t will be stored in. Does using DRAM make sense?
• Had to change WAIT FOR command to a WHILE loop. Someone with experience with Karel. Does my logic check out?
• ros_state.kl : Just like ros_relay.kl, changed SHADOW to DRAM
• After translating with WinOLPC no *.tp files were generated. 
• I have transferred all *.pc files to to controller. 
• Still need to find out if the tutorials will work. 

2. I need to create a MoveIt package for my robot.

• I know this is the way to go about it: http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot 
  
• I don't have a URDF file for my robot. Has anyone created a URDF file for a LR Mate 200iB 3L or created the MoveIt package? (fingers crossed)
• Any advice on how I go about doing this? I do need to read into it more. Just want to save time if I can.

Thanks for reading!

Lucas

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

On 17/04/15 23:37, Lucas Chavez wrote:
> Hello,

Hi Lucas,

> I am new to ROS Industrial, but I have used ROS Diamondback (back in 2011)
> for a mobile robot application.
>
> I am now tasked with getting ROS Industrial to work on a 2003 Fanuc LR Mate
> 200iB 3L whose controller is a HandlingTool R-J3iB Mate running version
> M6.11-1A without an iPendant. Also, I don't have Roboguide. I am relying on
> Fanuc's WinOLPC, PC File Services, and FRRobotDemo.
>

> Here is my dog Pepper with the robot. <http://i.imgur.com/QeLSBBm.jpg> In

> a shameless attempt to use my dog to get more help :)
>
> I have been diving into the documentation, reading posts here, and on ROS
> answers. I have a two major concerns, before I go deeper I want to list
> them and ask for answers/tips/opinions/help:

[..]

Getting this to run shouldn't be too difficult.

It would've probably been a good idea to email this list first though,
as I've had some dealings with older controllers in the past and have
some branches that improve compatibility with < 7.20 system versions
already. V6.11 wasn't one of them, but the changes required weren't too
great. Would've saved you some time possibly :).


I'll address the main aspects of getting it to run one-by-one (this will
probably answer most / all of your questions):

- URDF: I have an experimental pkg I made for another user some time
ago (he never returned, so it isn't finished). It's missing meshes
(currently using the 200i meshes), as I don't have them for the 200iB.
The kinematic structure is there though. If you provide me with meshes
for the 200iB I can easily update the pkg. If not, this should provide
you with a starting point. I've pushed it to my personal fork, see [1].

- IKFast: I never got round to creating an IKFast plugin for the
200iB, but it isn't too difficult. Latest versions of collada_to_urdf
segfault though, so it's easiest to do on a Hydro installation. If I get
some time next week I can probably do it (I've made a simple pkg that
automates most of the steps. Works only for simple serial chains though.
See [2]), but you're free to try yourself.

- MoveIt config: as I didn't have the correct meshes, creating a
MoveIt config didn't make sense (collision matrix would be bogus fi).
Creating these is trivial though and should take no more than a few minutes.

- Driver: the biggest challenges with these old(er) controllers are
multi-tasking and socket comm. Afaik, R-J3iB always have socket comm
(SKMG) and Karel support (KARL) installed, but multi-tasking (J600) is
not standard. You'll have to check that. If you don't have it, we can
probably write a Karel program that starts everything. The driver runs a
state reporter and a traj relay, so we need to be able to run those two
in parallel.

As to motion, the TP based proxy probably works, but personally I
think a Karel only approach makes more sense. I've pushed a version of
the driver that should be 6.11 compatible *and* uses Karel motion to my
personal fork [3]. Using the Makefile (and a Windows version of GNU
make) building should be easy (try: 'make SUPPORT_VER=V6.11-1', make
sure 'ktrans.exe' is on your path). It doesn't do TP programs yet
though, but you don't really need those, depending on your setup.

Keep in mind that this is all rather experimental, so you're bound to
run into *some* issues.


The tutorials should give you an idea of what you need to do to
configure everything, but obviously the screenshots and key sequences
will not be correct for your pendant. You also probably need to recreate
the TP programs, as importing them could prove difficult.

Be sure to check the Troubleshooting page [4] of fanuc_driver if you run
into any issues while following the tutorials.

See [5] for some pointers on how to work with these packages.


Contact me off-list if you run into anything else,


Gijs vd. Hoorn
DBL, DRI, TU Delft
the Netherlands

PS: I've rebased [3] it into hydro-devel.
PPS: I haven't been able to test the trajectory relay in the branch I
pushed, as the Roboguide simulation of V5.xx/6.xx socket comm is bugged.
The state reporter worked though, so I'm fairly confident it will work
on your real R-J3iB.


[1]
https://github.com/gavanderhoorn/fanuc_experimental/tree/lrmate200ib_support
[2] https://github.com/gavanderhoorn/moveit_ikfast_simpler
[3] https://github.com/gavanderhoorn/fanuc/tree/v611_karel_moveto
[4] http://wiki.ros.org/fanuc_driver/Troubleshooting
[5]
http://wiki.ros.org/Industrial/Tutorials/WorkingWithRosIndustrialRobotSupportPackages

[Lucas Chavez]

Gijs,

Thank you for such quick reply! I should have mentioned that I only work on the system Thursdays and Fridays. So I will look deeper into this tomorrow but below are my initial concerns. 

On Saturday, April 18, 2015 at 8:19:58 AM UTC-6, gavanderhoorn wrote:

On 17/04/15 23:37, Lucas Chavez wrote:
> Hello,

Hi Lucas,


> I am new to ROS Industrial, but I have used ROS Diamondback (back in 2011)
> for a mobile robot application.
>
> I am now tasked with getting ROS Industrial to work on a 2003 Fanuc LR Mate
> 200iB 3L whose controller is a HandlingTool R-J3iB Mate running version
> M6.11-1A without an iPendant. Also, I don't have Roboguide. I am relying on
> Fanuc's WinOLPC, PC File Services, and FRRobotDemo.
>
> Here is my dog Pepper with the robot. <http://i.imgur.com/QeLSBBm.jpg>  In
> a shameless attempt to use my dog to get more help :)
>
> I have been diving into the documentation, reading posts here, and on ROS
> answers. I have a two major concerns, before I go deeper I want to list
> them and ask for answers/tips/opinions/help:
[..]

Getting this to run shouldn't be too difficult.

It would've probably been a good idea to email this list first though,
as I've had some dealings with older controllers in the past and have
some branches that improve compatibility with < 7.20 system versions
already. V6.11 wasn't one of them, but the changes required weren't too
great. Would've saved you some time possibly :).

Makes sense. I felt that I should spend sometime trying to get it working myself in order to be knowledgable when asking questions. Also, it was a good intro into Karel.  

I'll address the main aspects of getting it to run one-by-one (this will
probably answer most / all of your questions):

  - URDF: I have an experimental pkg I made for another user some time
ago (he never returned, so it isn't finished). It's missing meshes
(currently using the 200i meshes), as I don't have them for the 200iB.
The kinematic structure is there though. If you provide me with meshes
for the 200iB I can easily update the pkg. If not, this should provide
you with a starting point. I've pushed it to my personal fork, see [1].

Ok great. I'll look into acquiring the meshes. How are these typically found with Fanuc?   

  - IKFast: I never got round to creating an IKFast plugin for the
200iB, but it isn't too difficult. Latest versions of collada_to_urdf
segfault though, so it's easiest to do on a Hydro installation. If I get
some time next week I can probably do it (I've made a simple pkg that
automates most of the steps. Works only for simple serial chains though.
See [2]), but you're free to try yourself.

I installed Ubuntu 14.04 so that is why I installed Indigo. Do you think it will be worth me changing to Ubuntu 13.04 in order to run Hydro? I was hoping to run the latest version of everything, but I can change that if it will mean less headaches.  

  - MoveIt config: as I didn't have the correct meshes, creating a
MoveIt config didn't make sense (collision matrix would be bogus fi).
Creating these is trivial though and should take no more than a few minutes.

  - Driver: the biggest challenges with these old(er) controllers are
multi-tasking and socket comm. Afaik, R-J3iB always have socket comm
(SKMG) and Karel support (KARL) installed, but multi-tasking (J600) is
not standard. You'll have to check that. If you don't have it, we can
probably write a Karel program that starts everything. The driver runs a
state reporter and a traj relay, so we need to be able to run those two
in parallel.

 Ok. I will check, but I doubt we have that option. 

   As to motion, the TP based proxy probably works, but personally I
think a Karel only approach makes more sense. I've pushed a version of
the driver that should be 6.11 compatible *and* uses Karel motion to my
personal fork [3]. Using the Makefile (and a Windows version of GNU
make) building should be easy (try: 'make SUPPORT_VER=V6.11-1', make
sure 'ktrans.exe' is on your path). It doesn't do TP programs yet
though, but you don't really need those, depending on your setup.

   Keep in mind that this is all rather experimental, so you're bound to
run into *some* issues.

Ok. I will look into that. Thanks for pushing that. Would it be worth adding some code to the main driver in order to make it v6 backward compatible "out of the box?" Or am I an outside case? I think we could make it compatible if there were Karel code that would allow it to check at translate time what version it is running. I could be responsible for pushing that to the hydro-devel branch if you think it would be a nice addition.   

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

On 22-4-2015 21:42, Lucas Chavez wrote:
> Gijs,
>
> Thank you for such quick reply! I should have mentioned that I only work on
> the system Thursdays and Fridays. So I will look deeper into this tomorrow
> but below are my initial concerns.

No problem, and see my responses in-line.

Newer robots may come with a CD/DVD with the manuals and some CAD
models. I don't know how this was done back in 2003, but you could try
and see whether you have anything there.

Alternatively, you might ask Fanuc if they could supply you with them if
you are still in contact with them.

If we cannot get hold of actual meshes, approximations using geometric
primitives are also acceptable, but things will look a lot less nice in
RViz.

>> - IKFast: I never got round to creating an IKFast plugin for the
>> 200iB, but it isn't too difficult. Latest versions of collada_to_urdf
>> segfault though, so it's easiest to do on a Hydro installation. If I get
>> some time next week I can probably do it (I've made a simple pkg that
>> automates most of the steps. Works only for simple serial chains though.
>> See [2]), but you're free to try yourself.
>>
>
> I installed Ubuntu 14.04 so that is why I installed Indigo. Do you think it
> will be worth me changing to Ubuntu 13.04 in order to run Hydro? I was
> hoping to run the latest version of everything, but I can change that if it
> will mean less headaches.

The plugin needs to be generated only once, after that it is just a
static source file. You could take the 200ib pkg I pushed and use a
Hydro system just once to get the plugin generated.

It would also obviously be very much appreciated if someone finally
solved the collada / assimp issues with the collada_to_urdf node on
Indigo, but that may be a bit out of scope :).

>> - MoveIt config: as I didn't have the correct meshes, creating a
>> MoveIt config didn't make sense (collision matrix would be bogus fi).
>> Creating these is trivial though and should take no more than a few
>> minutes.
>>
>> - Driver: the biggest challenges with these old(er) controllers are
>> multi-tasking and socket comm. Afaik, R-J3iB always have socket comm
>> (SKMG) and Karel support (KARL) installed, but multi-tasking (J600) is
>> not standard. You'll have to check that. If you don't have it, we can
>> probably write a Karel program that starts everything. The driver runs a
>> state reporter and a traj relay, so we need to be able to run those two
>> in parallel.
>>
>
> Ok. I will check, but I doubt we have that option.

We can always opt for the Karel program, it should work just as well.

>> As to motion, the TP based proxy probably works, but personally I
>> think a Karel only approach makes more sense. I've pushed a version of
>> the driver that should be 6.11 compatible *and* uses Karel motion to my
>> personal fork [3]. Using the Makefile (and a Windows version of GNU
>> make) building should be easy (try: 'make SUPPORT_VER=V6.11-1', make
>> sure 'ktrans.exe' is on your path). It doesn't do TP programs yet
>> though, but you don't really need those, depending on your setup.
>>
>> Keep in mind that this is all rather experimental, so you're bound to
>> run into *some* issues.
>>
> Ok. I will look into that. Thanks for pushing that. Would it be worth
> adding some code to the main driver in order to make it v6 backward
> compatible "out of the box?" Or am I an outside case? I think we could make
> it compatible if there were Karel code that would allow it to check at
> translate time what version it is running. I could be responsible for
> pushing that to the hydro-devel branch if you think it would be a nice
> addition.

I'm a bit confused about what you mean with 'at translate time': Karel
is a compiled language with no 'preprocessor' kind-of front-end, so I'm
not sure we can 'detect' anything then.

It is certainly possible to detect some things at runtime though, but
the current version of the driver is rather minimal in its
functionality, and especially system variable access is hard coded. A
future revision will probably rectify these kind of things (and more).

You're certainly not an outside case, but I'd rather keep the focus on
post V7.20 systems for the time being (there are enough quirks already).

[Lucas Chavez]

The Karel code translated successfully and is now on the controller. Yay! We do not have Multi-Tasking (J600). I have not done anything further than transfer the .pc files. I believe I need to change my Karel code because I do not have Multi-Tasking. I wanted your opinion and advice before proceeding. See my full response in line. 

We do not have access to the meshes. I will search the internet. But for right now, thank you for pushing that branch to fanuc_experimental with the 200i meshes. 

>>   - IKFast: I never got round to creating an IKFast plugin for the
>> 200iB, but it isn't too difficult. Latest versions of collada_to_urdf
>> segfault though, so it's easiest to do on a Hydro installation. If I get
>> some time next week I can probably do it (I've made a simple pkg that
>> automates most of the steps. Works only for simple serial chains though.
>> See [2]), but you're free to try yourself.
>>
>
> I installed Ubuntu 14.04 so that is why I installed Indigo. Do you think it
> will be worth me changing to Ubuntu 13.04 in order to run Hydro? I was
> hoping to run the latest version of everything, but I can change that if it
> will mean less headaches.  

The plugin needs to be generated only once, after that it is just a
static source file. You could take the 200ib pkg I pushed and use a
Hydro system just once to get the plugin generated.

It would also obviously be very much appreciated if someone finally
solved the collada / assimp issues with the collada_to_urdf node on
Indigo, but that may be a bit out of scope :).

Do I need the IKFast plugin to run: http://wiki.ros.org/fanuc/Tutorials/Running ? Prerequisites say just the MoveIt package. But I'm not quite sure what IKFast is for. My current plan (after running that tutorial) is to try and generate the plugin. I have some background in C++ so if it's easy maybe I can fix it and be a good open source user. If not, I'll create a virtual machine of Ubuntu 13 in Ubuntu 14 :)

>>   - MoveIt config: as I didn't have the correct meshes, creating a
>> MoveIt config didn't make sense (collision matrix would be bogus fi).
>> Creating these is trivial though and should take no more than a few
>> minutes.
>>
>>   - Driver: the biggest challenges with these old(er) controllers are
>> multi-tasking and socket comm. Afaik, R-J3iB always have socket comm
>> (SKMG) and Karel support (KARL) installed, but multi-tasking (J600) is
>> not standard. You'll have to check that. If you don't have it, we can
>> probably write a Karel program that starts everything. The driver runs a
>> state reporter and a traj relay, so we need to be able to run those two
>> in parallel.
>>

This is the main issue! How can I write a Karel program that starts everything? How much help are you willing to give here? Any is fine but I am asking because you mentioned "we." What can I do to make this happen? 

>
>  Ok. I will check, but I doubt we have that option.

We can always opt for the Karel program, it should work just as well.

We don't have the Multi-Tasking option. 

>>    As to motion, the TP based proxy probably works, but personally I
>> think a Karel only approach makes more sense. I've pushed a version of
>> the driver that should be 6.11 compatible *and* uses Karel motion to my
>> personal fork [3]. Using the Makefile (and a Windows version of GNU
>> make) building should be easy (try: 'make SUPPORT_VER=V6.11-1', make
>> sure 'ktrans.exe' is on your path). It doesn't do TP programs yet
>> though, but you don't really need those, depending on your setup.
>>
>>    Keep in mind that this is all rather experimental, so you're bound to
>> run into *some* issues.
>>
> Ok. I will look into that. Thanks for pushing that. Would it be worth
> adding some code to the main driver in order to make it v6 backward
> compatible "out of the box?" Or am I an outside case? I think we could make
> it compatible if there were Karel code that would allow it to check at
> translate time what version it is running. I could be responsible for
> pushing that to the hydro-devel branch if you think it would be a nice
> addition.

 

   

The code translated and is now on the controller. I don't know what you mean by "karel motion"

I'm a bit confused about what you mean with 'at translate time': Karel
is a compiled language with no 'preprocessor' kind-of front-end, so I'm
not sure we can 'detect' anything then.

 

Right I wasn't making sense there. I meant just to put checks in the karel code to see if the version is older. This is because the difference between your v6_karel_moveto branch and the current hydro-devel isn't much. If we can do checks we could combine the two fanuc_driver folders and it would work for v6 and v7. For example, in libind_log.kl the main difference is the message doesn't have color options. In your v6_karel_moveto branch these lines are simply commented out. I'm saying something like (in pseudocode):

if v7

  message print using code from current hydro-devel branch 

else

  message print using code from v6_karel_moveto

end

It is certainly possible to detect some things at runtime though, but
the current version of the driver is rather minimal in its
functionality, and especially system variable access is hard coded. A
future revision will probably rectify these kind of things (and more).

It seems v6 doesn't define  the variable "cc_yellow" (see libind_log.kl). Do you think that is a reliable way to see if the karel code is running on a v6 controller? 

You're certainly not an outside case, but I'd rather keep the focus on
post V7.20 systems for the time being (there are enough quirks already).

I understand that. The thing I was trying to avoid was someone developing on the hydro-devel in the fanuc_driver folder and then having to transfer to a separate v6 specific branch like your v6_karel_moveto. Mainly it's not obvious where to get it from. Also, all the horrors of duplicate code and stuff. So just to double check, since it seems you have the greatest knowledge slash investment in this repo, if I made a pull request in the karel_drive folder with if statements similar to the pseudocode above do you think it will help the repo?

>> The tutorials should give you an idea of what you need to do to
>> configure everything, but obviously the screenshots and key sequences
>> will not be correct for your pendant. You also probably need to recreate
>> the TP programs, as importing them could prove difficult.
>>

So I will need the TP programs?

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

On 24-4-2015 23:13, Lucas Chavez wrote:
> The Karel code translated successfully and is now on the controller. Yay!
> We do not have Multi-Tasking (J600). I have not done anything further than
> transfer the .pc files. I believe I need to change my Karel code because I
> do not have Multi-Tasking. I wanted your opinion and advice before
> proceeding. See my full response in line.

Multi-tasking is not needed for the Karel programs, the option extends
TP to allow running multiple programs in parallel.

Responses in-line again (I normally don't top-post, so all my responses
will be in-line).


[..]

>>>> - URDF: I have an experimental pkg I made for another user some time
>>>> ago (he never returned, so it isn't finished). It's missing meshes
>>>> (currently using the 200i meshes), as I don't have them for the 200iB.
>>>> The kinematic structure is there though. If you provide me with meshes
>>>> for the 200iB I can easily update the pkg. If not, this should provide
>>>> you with a starting point. I've pushed it to my personal fork, see [1].
>>>>
>>>
>>> Ok great. I'll look into acquiring the meshes. How are these typically
>>> found with Fanuc?
>>
>> Newer robots may come with a CD/DVD with the manuals and some CAD
>> models. I don't know how this was done back in 2003, but you could try
>> and see whether you have anything there.
>>
>> Alternatively, you might ask Fanuc if they could supply you with them if
>> you are still in contact with them.
>>
>> If we cannot get hold of actual meshes, approximations using geometric
>> primitives are also acceptable, but things will look a lot less nice in
>> RViz.
>>
> We do not have access to the meshes. I will search the internet. But for
> right now, thank you for pushing that branch to fanuc_experimental with the
> 200i meshes.

Note that for simple control of the robot you don't need the meshes:
RViz will show a robot that does not correspond to your own, but that is
only visualisation.

However, if you plan to use MoveIt and want to rely on its collision
detection / avoidance, you _will_ need the correct meshes, as it relies
on them for that piece of functionality. As I wrote earlier: you can
work around this a bit by piecing together your collision model from
geometric primitives.

>>>> - IKFast: I never got round to creating an IKFast plugin for the
>>>> 200iB, but it isn't too difficult. Latest versions of collada_to_urdf
>>>> segfault though, so it's easiest to do on a Hydro installation. If I get
>>>> some time next week I can probably do it (I've made a simple pkg that
>>>> automates most of the steps. Works only for simple serial chains though.
>>>> See [2]), but you're free to try yourself.
>>>>
>>>
>>> I installed Ubuntu 14.04 so that is why I installed Indigo. Do you think it
>>> will be worth me changing to Ubuntu 13.04 in order to run Hydro? I was
>>> hoping to run the latest version of everything, but I can change that if it
>>> will mean less headaches.
>>
>> The plugin needs to be generated only once, after that it is just a
>> static source file. You could take the 200ib pkg I pushed and use a
>> Hydro system just once to get the plugin generated.
>>
>> It would also obviously be very much appreciated if someone finally
>> solved the collada / assimp issues with the collada_to_urdf node on
>> Indigo, but that may be a bit out of scope :).
>>
> Do I need the IKFast plugin to run:
> http://wiki.ros.org/fanuc/Tutorials/Running ? Prerequisites say just the
> MoveIt package. But I'm not quite sure what IKFast is for. My current plan
> (after running that tutorial) is to try and generate the plugin. I have
> some background in C++ so if it's easy maybe I can fix it and be a good
> open source user. If not, I'll create a virtual machine of Ubuntu 13 in
> Ubuntu 14 :)

No you don't need it. In fact, it is never really 'needed', as the
default KDL based ik plugin also works. IKFast is just much faster and
is what we typically use in ROS-I (or at least: I try to release IKFast
based plugins for all the Fanuc pkgs I create).

>>>> - MoveIt config: as I didn't have the correct meshes, creating a
>>>> MoveIt config didn't make sense (collision matrix would be bogus fi).
>>>> Creating these is trivial though and should take no more than a few
>>>> minutes.
>>>>
>>>> - Driver: the biggest challenges with these old(er) controllers are
>>>> multi-tasking and socket comm. Afaik, R-J3iB always have socket comm
>>>> (SKMG) and Karel support (KARL) installed, but multi-tasking (J600) is
>>>> not standard. You'll have to check that. If you don't have it, we can
>>>> probably write a Karel program that starts everything. The driver runs a
>>>> state reporter and a traj relay, so we need to be able to run those two
>>>> in parallel.
>>>>
>>
> This is the main issue! How can I write a Karel program that starts
> everything? How much help are you willing to give here? Any is fine but I
> am asking because you mentioned "we." What can I do to make this happen?
>
>>>
>>> Ok. I will check, but I doubt we have that option.
>>
>> We can always opt for the Karel program, it should work just as well.
>>
> We don't have the Multi-Tasking option.

I've pushed a small utility Karel program to [3] that you should be able
to use instead of J600. It uses the Karel RUN_TASK() routine to start a
program 'in the background', then quits.

I've also updated the main ROS tp program (in 'tpe/ros.ls') to show you
how to use it. We could've written a Karel program that started
everything, but this is less invasive.

>>>> As to motion, the TP based proxy probably works, but personally I
>>>> think a Karel only approach makes more sense. I've pushed a version of
>>>> the driver that should be 6.11 compatible *and* uses Karel motion to my
>>>> personal fork [3]. Using the Makefile (and a Windows version of GNU
>>>> make) building should be easy (try: 'make SUPPORT_VER=V6.11-1', make
>>>> sure 'ktrans.exe' is on your path). It doesn't do TP programs yet
>>>> though, but you don't really need those, depending on your setup.
>>>>
>>>> Keep in mind that this is all rather experimental, so you're bound to
>>>> run into *some* issues.
>>>>
>>> Ok. I will look into that. Thanks for pushing that. Would it be worth
>>> adding some code to the main driver in order to make it v6 backward
>>> compatible "out of the box?" Or am I an outside case? I think we could make
>>> it compatible if there were Karel code that would allow it to check at
>>> translate time what version it is running. I could be responsible for
>>> pushing that to the hydro-devel branch if you think it would be a nice
>>> addition.
>
> The code translated and is now on the controller. I don't know what you
> mean by "karel motion"

There are two ways to control motion on a Fanuc controller: the
recommended way nowadays is through TP programs. Karel programs can also
command motion, but that has been deprecated. On a R-J3iB though, I
think we can still use the Karel motion instructions.

>> I'm a bit confused about what you mean with 'at translate time': Karel
>> is a compiled language with no 'preprocessor' kind-of front-end, so I'm
>> not sure we can 'detect' anything then.
>>
>
> Right I wasn't making sense there. I meant just to put checks in the karel
> code to see if the version is older. This is because the difference between
> your v6_karel_moveto branch and the current hydro-devel isn't much. If we
> can do checks we could combine the two fanuc_driver folders and it would
> work for v6 and v7. For example, in libind_log.kl the main difference is
> the message doesn't have color options. In your v6_karel_moveto branch
> these lines are simply commented out. I'm saying something like (in
> pseudocode):
>
> if v7
>
> message print using code from current hydro-devel branch
>
> else
> message print using code from v6_karel_moveto
> end
>
>
>> It is certainly possible to detect some things at runtime though, but
>> the current version of the driver is rather minimal in its
>> functionality, and especially system variable access is hard coded. A
>> future revision will probably rectify these kind of things (and more).
>>
>
> It seems v6 doesn't define the variable "cc_yellow" (see libind_log.kl).
> Do you think that is a reliable way to see if the karel code is running on
> a v6 controller?

'cc_yellow' is not a variable, it is a constant, defined in a header
supplied by Fanuc. We cannot use it to detect things at runtime. But it
is possible in some cases to do runtime detection of features, and I do
agree that is a much better approach than hard-coding things.

Furthermore, the support for colours is not only determined by which
system version is running on the controller: it is the display device
that needs to support them. I'd consider detecting what kind of pendant
is connected a more robust way of knowing when to use colour.

>> You're certainly not an outside case, but I'd rather keep the focus on
>> post V7.20 systems for the time being (there are enough quirks already).
>>
> I understand that. The thing I was trying to avoid was someone developing
> on the hydro-devel in the fanuc_driver folder and then having to transfer
> to a separate v6 specific branch like your v6_karel_moveto. Mainly it's not
> obvious where to get it from. Also, all the horrors of duplicate code and
> stuff. So just to double check, since it seems you have the greatest
> knowledge slash investment in this repo, if I made a pull request in the
> karel_drive folder with if statements similar to the pseudocode above do
> you think it will help the repo?

I'll always consider PRs and I welcome your contributions, but to get
proper support for older controller / system versions into the driver
requires more than just the changes I pushed to [3]. I just wanted to
make something available to you quickly. That is also the reason it was
'not obvious where to get it from': not all existing code is up on
github, and I just branched the repo for you on my personal fork. It is
not intended to become the 'official' way of maintaining versions of the
driver targeting different runtime systems.

As to adding checks: the logging code is currently part of the critical
path in the programs and I'd like to avoid adding too many branching
statements there. It's only a single branch now, but I prefer a more
structured approach (such as refactoring the logging infrastructure to
run in a separate program).

>>>> The tutorials should give you an idea of what you need to do to
>>>> configure everything, but obviously the screenshots and key sequences
>>>> will not be correct for your pendant. You also probably need to
>> recreate
>>>> the TP programs, as importing them could prove difficult.
>>>>
>>
> So I will need the TP programs?

I recommend you create at least one TP program that just starts
everything up, as this will be easier to manage, especially if you don't
have too much experience yet.

Look at the 'tpe/ros.ls' file for an example. That should be easy to
recreate using the pendant. Alternatively, you could translate it using
WinOLPC and then copy it to your controller.

Obviously, you'll have to adjust some of the instructions given in the
tutorials, as some will not apply to your situation. In general it
should still all work though.

[Lucas Chavez]

This thread is getting long. So I am going to post from scratch and reference back when needed. 

First. Thank you for all of your help so far Gijs (gavanderhoorn)! 

Currently I have the 2nd roslaunch command from http://wiki.ros.org/fanuc/Tutorials/Running running. I can move the robot with the teach pendant and see the visualized robot move in rviz. I was unable to run the 1st because we do not have Roboguide. 

Rundown of steps to get here:

• I got the karel driver from https://github.com/gavanderhoorn/fanuc/tree/v611_karel_moveto. I translated all the karel code and transferred it onto the controller. I was then trying to follow step 7 of http://wiki.ros.org/fanuc/Tutorials/hydro/Configuration. I did not have the option of [TYPE]->KAREL Vars. Some googling searching revealed that although I have KAREL Run-Time Env,J539 I don't have KAREL installed on the controller. So I cannot edit the variables from the pendant. So I went and set cfg.checked = TRUE in ros_state.kl and ros_relay.kl. Luckily the defaults worked fine for me. Is there any better way to do this? I can see the variables from FRRobotDemo but I can not change them. PS. I really like that Makefile in fanuc_driver/karel. Much better than using WinOLPC. 
  
• I then made a catkin workspace and followed the instructions on step 4 of http://wiki.ros.org/fanuc_experimental. I substituted https://github.com/ros-industrial/fanuc_experimental.git with https://github.com/gavanderhoorn/fanuc_experimental.git and also switched to branch lrmate200ib_support. 
  
• I had to start the ROS_STATE karel program from the xp machine using FRRobotDemo.
  

The above was all before your commit "driver: add tp RUN surrogate for ctrlrs without J600 (Multi-tasking)." Just today, I followed the same steps as above and all the karel code translated and transferred just fine. I then turned my attention to the ros.ls file. I tried following what you had said:

Look at the 'tpe/ros.ls' file for an example. That should be easy to 
recreate using the pendant. Alternatively, you could translate it using 
WinOLPC and then copy it to your controller. 

But I was not able to translate. Some googling showed that I probably need the "ASCII Upload" option. We do not have that. I then tried:

ktrans.exe ros.ls /ver V6.11-1

That didn't work either. Here is a list of other .exe files in the folder where ktrans.exe is found: kcdict.exe, kconvars.exe, ktrans.exe, maketp.exe, printtp.exe, setrobot.exe. Would any of these work?

Is my only option to copy by hand the ros.ls file onto the pendant? 

My goal now is the run the 3rd roslaunch from http://wiki.ros.org/fanuc/Tutorials/Running. I know I need to make a moveit configuration package for this. I plan to use the meshes from the 200i from https://github.com/gavanderhoorn/fanuc_experimental/tree/lrmate200ib_support. I haven't been able to get the meshes for the 200ib and right now it is not a priority. I just want things to be working. Things I know:

• I think I need to follow this http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot
  
• I think this will help me https://github.com/gavanderhoorn/moveit_ikfast_simpler. But I haven't looked into it yet. 
  
• Am I missing anything?

Other Questions/Comments:

 - URDF: I have an experimental pkg I made for another user some time 
ago (he never returned, so it isn't finished). It's missing meshes 
(currently using the 200i meshes), as I don't have them for the 200iB. 
The kinematic structure is there though. If you provide me with meshes 
for the 200iB I can easily update the pkg. If not, this should provide 
you with a starting point. I've pushed it to my personal fork, see [1]. 

Where did the kinematic structure come from? 

I've also updated the main ROS tp program (in 'tpe/ros.ls') to show you 
how to use it. We could've written a Karel program that started 
everything, but this is less invasive. 

Given the information above. Maybe a karel program is the way to go?

There are two ways to control motion on a Fanuc controller: the 
recommended way nowadays is through TP programs. Karel programs can also 
command motion, but that has been deprecated. On a R-J3iB though, I 
think we can still use the Karel motion instructions. 

Will this affect the robot movement? Maybe make it less smooth? 

I will look into the IKFast plugin later down the road. Not a priority right now. 

Thanks again!

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

On 09/05/15 00:19, Lucas Chavez wrote:
> This thread is getting long. So I am going to post from scratch and
> reference back when needed.
>
> First. Thank you for all of your help so far Gijs (gavanderhoorn)!
>
> Currently I have the 2nd roslaunch command from
> http://wiki.ros.org/fanuc/Tutorials/Running running. I can move the robot
> with the teach pendant and see the visualized robot move in rviz. I was
> unable to run the 1st because we do not have Roboguide.

That's not really a problem. The tutorial is rather conservative, and
the first step is just to make sure people get a feel of what is needed
/ going on.

> Rundown of steps to get here:
>

> - I got the karel driver from

> https://github.com/gavanderhoorn/fanuc/tree/v611_karel_moveto. I
> translated all the karel code and transferred it onto the controller. I was
> then trying to follow step 7 of
> http://wiki.ros.org/fanuc/Tutorials/hydro/Configuration. I did not have
> the option of [TYPE]->KAREL Vars. Some googling searching revealed that
> although I have KAREL Run-Time Env,J539 I don't have KAREL installed on the
> controller. So I cannot edit the variables from the pendant. So I went and
> set cfg.checked = TRUE in ros_state.kl and ros_relay.kl. Luckily the
> defaults worked fine for me. Is there any better way to do this? I can see
> the variables from FRRobotDemo but I can not change them. PS. I really like
> that Makefile in fanuc_driver/karel. Much better than using WinOLPC.

hm, ok. That is different from what I've seen earlier on older
controllers. Are Karel programs visible in the Program Select window
([SELECT] button on TP, [TYPE]->KAREL)? If not, please see [1].

re: config: if you cannot access the KAREL vars, then what you did is
actually currently the only option (see [2]). But do please check [1].

In general: I'd recommend you first check [3] if anything doesn't work /
isn't there.


> - I then made a catkin workspace and followed the instructions on step 4

> of http://wiki.ros.org/fanuc_experimental. I substituted
> https://github.com/ros-industrial/fanuc_experimental.git with
> https://github.com/gavanderhoorn/fanuc_experimental.git and also
> switched to branch lrmate200ib_support.

All correct.


> - I had to start the ROS_STATE karel program from the xp machine using
> FRRobotDemo.

Can you tell me why exactly? Is this also still needed after you've
checked [1]?

See comment further down about TP programs.

> The above was all before your commit "driver: add tp RUN surrogate for
> ctrlrs without J600 (Multi-tasking)." Just today, I followed the same steps
> as above and all the karel code translated and transferred just fine. I
> then turned my attention to the ros.ls file. I tried following what you had
> said:
>
>> Look at the 'tpe/ros.ls' file for an example. That should be easy to
>> recreate using the pendant. Alternatively, you could translate it using
>> WinOLPC and then copy it to your controller.
>
> But I was not able to translate. Some googling showed that I probably need
> the "ASCII Upload" option. We do not have that. I then tried:
> ktrans.exe ros.ls /ver V6.11-1
> That didn't work either. Here is a list of other .exe files in the folder
> where ktrans.exe is found: kcdict.exe, kconvars.exe, ktrans.exe,
> maketp.exe, printtp.exe, setrobot.exe. Would any of these work?
> Is my only option to copy by hand the ros.ls file onto the pendant?

re: ascii upload: that would be nice, but is not needed. Also, could you
send me a list of the options you do have? Easiest is probably through
'orderfil.dat' in a 'all of above' backup of your controller.

re: copying to controller: you just need to 'translate' the ls listing
first before you can copy them to the controller. That is what
'maketp.exe' is for. Check your manuals / winolpc help for how to setup
a 'virtual robot', use 'setrobot.exe' and finally how to invoke
'maketp.exe'.

I can provide you with the binary versions of the required files, but
it's probably worth it investing some time to be able to do this yourself.

> My goal now is the run the 3rd roslaunch from
> http://wiki.ros.org/fanuc/Tutorials/Running. I know I need to make a moveit
> configuration package for this. I plan to use the meshes from the 200i from
> https://github.com/gavanderhoorn/fanuc_experimental/tree/lrmate200ib_support.
> I haven't been able to get the meshes for the 200ib and right now it is not
> a priority. I just want things to be working.

As long as you understand that MoveIt cannot do reliable collision
avoidance without those meshes.


> Things I know:
>
> - I think I need to follow this
> http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot
> - I think this will help me

> https://github.com/gavanderhoorn/moveit_ikfast_simpler. But I haven't
> looked into it yet.

> - Am I missing anything?

No, that is correct. Two things:

1. you can probably use fanuc_lrmate200i_moveit_config as inspiration
/ verification for your moveit pkg (see [4])
2. forget about the ikfast plugin for now. It's not necessary and can
just as well be done later

> Other Questions/Comments:
>
>> - URDF: I have an experimental pkg I made for another user some time
>> ago (he never returned, so it isn't finished). It's missing meshes
>> (currently using the 200i meshes), as I don't have them for the 200iB.
>> The kinematic structure is there though. If you provide me with meshes
>> for the 200iB I can easily update the pkg. If not, this should provide
>> you with a starting point. I've pushed it to my personal fork, see [1].
>
> Where did the kinematic structure come from?

I created it, based on data from the controller and the datasheets for
the 200i.

>> I've also updated the main ROS tp program (in 'tpe/ros.ls') to show you
>> how to use it. We could've written a Karel program that started
>> everything, but this is less invasive.
>
> Given the information above. Maybe a karel program is the way to go?

No. First check [1]. If that doesn't apply, just create the TP program
by hand on the TP. It's only a single one (ros.ls), and it contains only
3 or 4 lines.

>> There are two ways to control motion on a Fanuc controller: the
>> recommended way nowadays is through TP programs. Karel programs can also
>> command motion, but that has been deprecated. On a R-J3iB though, I
>> think we can still use the Karel motion instructions.
>
> Will this affect the robot movement? Maybe make it less smooth?

It will, but only in specific use cases. If anything, it will make it
smoother, but there are trade-offs. See also [5]: the way the Karel
motion commands are used in 'your' branch is something close to CNT80,
but with dense paths that should not be too much of an issue.

If you can tell me what you intend to do with your 200iB, I could tell
you whether that is feasible with the current state of the driver.

And an additional warning: check and see whether your controller has
more than one motion group configured. If it has, 'officially' you're
not supposed to use Karel motion.

> I will look into the IKFast plugin later down the road. Not a priority
> right now.

As I said, ignore for now.


> Thanks again!

No problem.


Gijs

[1]
http://wiki.ros.org/fanuc_driver/Troubleshooting#KAREL_programs_are_invisible_on_the_Program_Select_window
[2]
http://wiki.ros.org/fanuc/Tutorials/hydro/Installation#Installation_options
[3] http://wiki.ros.org/fanuc_driver/Troubleshooting
[4]
https://github.com/gavanderhoorn/fanuc_experimental/tree/lrmate200i_support
[5]
http://wiki.ros.org/fanuc/Tutorials/hydro/Configuration#Motion_Speed_and_Segment_Termination

[Lucas Chavez]

Thanks for all your help so far and thank you to whoever contributed the meshes for the 300iB and 300iB3L.

I checked with [1] and our Karel programs are visible. 

>  - I had to start the ROS_STATE karel program from the xp machine using 
>  FRRobotDemo. 
Can you tell me why exactly? Is this also still needed after you've 
checked [1]? 

This is because we had not made any TP programs and we are unable to run Karel programs from our pendant. I believe FRRobotDemo was our only way to run the Karel program. I know now that we can use the rosstate.ls file to write the TP program by hand. 

Attached is a text file and pdf of a summary of our robot's configuration. It comes from our robot's web server. The text file is the same information just in a more convenient text file form. 

re: copying to controller: you just need to 'translate' the ls listing 
first before you can copy them to the controller. That is what 
'maketp.exe' is for. Check your manuals / winolpc help for how to setup 
a 'virtual robot', use 'setrobot.exe' and finally how to invoke 
'maketp.exe'. 

I want to be able to translate ls files to tp files this way. For now we wrote the ros.ls file into the pendant by hand (you mentioned doing it by hand in the last post as well). We were then able to run the ros.tp program from the pendent. The first time we ran it, we got errors. The second time, we didn't. Attached are pictures of the pendent showing what it looked like after the first and second times running ros.tp. Do you know why we got errors? I checked the troubleshooting page. 

If you can tell me what you intend to do with your 200iB, I could tell 
you whether that is feasible with the current state of the driver. 

We want to use it for intelligent prosthetic research. So pick and place applications.

We have not run the 3rd tutorial from the running tutorial page because I have not made a MoveIt config package with the new meshes. I know it will be a headache with my version of Ubuntu. I was wondering, would you be willing to make a MoveIt package? You had mentioned before that you could do it easily. If not, I'll dive into that next week. 

Thanks!

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

On 23/05/15 01:58, Lucas Chavez wrote:
> Thanks for all your help so far and thank you to whoever contributed the
> meshes for the 300iB and 300iB3L.
>
> I checked with [1] and our Karel programs are visible.
>
>>> - I had to start the ROS_STATE karel program from the xp machine using
>>> FRRobotDemo.
>> Can you tell me why exactly? Is this also still needed after you've
>> checked [1]?
>
> This is because we had not made any TP programs and we are unable to run
> Karel programs from our pendant. I believe FRRobotDemo was our only way to
> run the Karel program. I know now that we can use the rosstate.ls file to
> write the TP program by hand.
>
> Attached is a text file and pdf of a summary of our robot's configuration.
> It comes from our robot's web server. The text file is the same information
> just in a more convenient text file form.

Thanks for that. Comparing your list with what I know it seems you are
missing some Karel related options, so it is well possible that you
can't access the 'Karel Vars' or start the programs directly.

>> re: copying to controller: you just need to 'translate' the ls listing
>> first before you can copy them to the controller. That is what
>> 'maketp.exe' is for. Check your manuals / winolpc help for how to setup
>> a 'virtual robot', use 'setrobot.exe' and finally how to invoke
>> 'maketp.exe'.
>
> I want to be able to translate ls files to tp files this way. For now we
> wrote the ros.ls file into the pendant by hand (you mentioned doing it by
> hand in the last post as well).

Ok, good. It's only a few lines, so that should not have taken too long.

Just check your manuals for using winolpc.

> We were then able to run the ros.tp program
> from the pendent. The first time we ran it, we got errors. The second time,
> we didn't. Attached are pictures of the pendent showing what it looked like
> after the first and second times running ros.tp. Do you know why we got
> errors? I checked the troubleshooting page.

The INTP-112 is something I need to confirm with Fanuc, but should not
be related to the 'real issue', which is that it seems the configuration
of the ros_state program is incomplete. This is actually covered by the
Troubleshooting page (see [6]). Simply restarting ros_state should not
have solved this.

In general, if you get errors, please check the Alarm Log, either
through the TP or via the web server. For the 'check cfg' error, you
should see a FILE-032 (Illegal Parameter) in the log. Both ros_state and
ros_relay can post that error if something is not right with either of
their configurations.

Checking the Alarm Log is something I'd always do btw, when things don't
work as you think they should.

As to your second screenshot: it only shows the output of ros_relay, but
that could be an artefact of how the logging works. If in doubt, just
check the 'Program Status Information' on your controller's web server.
Both programs should be running.

>> If you can tell me what you intend to do with your 200iB, I could tell
>> you whether that is feasible with the current state of the driver.
>
> We want to use it for intelligent prosthetic research. So pick and place
> applications.

Ok, that should be fine.

> We have not run the 3rd tutorial from the running tutorial page because I
> have not made a MoveIt config package with the new meshes. I know it will
> be a headache with my version of Ubuntu. I was wondering, would you be
> willing to make a MoveIt package? You had mentioned before that you could
> do it easily. If not, I'll dive into that next week.

It's not the MoveIt configuration that is difficult to create, it's the
IKFast plugin. Recent versions of the urdf_to_collada scripts had a
tendency to crash. That could been solved already, but I wanted to tell
you just in case.

It's probably a good idea to create the MoveIt configuration yourself,
as you'll have to do it anyway if you ever want to create a proper work
cell urdf for your setup (add a gripper, define walls, etc). The "Create
a MoveIt Package for an Industrial Robot" tutorial should help you with
that, see [7].

As to the IKFast plugin: it isn't required for basic operation /
testing, so you can do without it for now. The default KDL based one
will work fine. The general process of creating these plugins is
described in [8].


Gijs

[6]
http://wiki.ros.org/fanuc_driver/Troubleshooting#FILE-032:_Illegal_parameter
[7]
http://wiki.ros.org/Industrial/Tutorials/Create_a_MoveIt_Pkg_for_an_Industrial_Robot
[8] http://moveit.ros.org/wiki/Kinematics/IKFast

[Lucas Chavez]

Thanks for that. Comparing your list with what I know it seems you are 
missing some Karel related options, so it is well possible that you 
can't access the 'Karel Vars' or start the programs directly. 

Ok. Good to know.

Ok, good. It's only a few lines, so that should not have taken too long. 
Just check your manuals for using winolpc. 

Nope. Didn't take long. Will check on winolpc in the future.

I will address the issues that came from running ros.tp in more depth tomorrow. For now, I was aware of [6]. I believe the solution on [6] is related to my specific issue of not being able to change Karel Variables through the pendant. Here is quote from earlier in our post of what I had to do. 

Rundown of steps to get here:

• I got the karel driver from https://github.com/gavanderhoorn/fanuc/tree/v611_karel_moveto. I translated all the karel code and transferred it onto the controller. I was then trying to follow step 7 of http://wiki.ros.org/fanuc/Tutorials/hydro/Configuration. I did not have the option of [TYPE]->KAREL Vars. Some googling searching revealed that although I have KAREL Run-Time Env,J539 I don't have KAREL installed on the controller. So I cannot edit the variables from the pendant. So I went and set cfg.checked = TRUE in ros_state.kl and ros_relay.kl. Luckily the defaults worked fine for me. Is there any better way to do this? I can see the variables from FRRobotDemo but I can not change them. PS. I really like that Makefile in fanuc_driver/karel. Much better than using WinOLPC. 

I'll check the alarm log tomorrow. 

The major thing I want to discuss today are some problems I have while following [7].  I got to section 2.1 and after hitting Plan, planning failed for my robot. Attached is the terminal output. Here is a short video https://www.youtube.com/watch?v=b8hJwj721fk&feature=youtu.be showing a screen capture of this happening (I had to use youtube because the attachment was too big, also it wouldn't let me make it into a link for some reason). I get several errors. Can you point me in the right place to start debugging? 

I was also able to run section 3.1. The path the planner came up with was very long and sporadic. 

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

On 04/06/15 23:42, Lucas Chavez wrote:
>> Thanks for that. Comparing your list with what I know it seems you are
>> missing some Karel related options, so it is well possible that you
>> can't access the 'Karel Vars' or start the programs directly.
>
> Ok. Good to know.
>
>> Ok, good. It's only a few lines, so that should not have taken too long.
>> Just check your manuals for using winolpc.
>
> Nope. Didn't take long. Will check on winolpc in the future.
>
> I will address the issues that came from running ros.tp in more depth
> tomorrow. For now, I was aware of [6]. I believe the solution on [6] is
> related to my specific issue of not being able to change Karel Variables
> through the pendant. Here is quote from earlier in our post of what I had
> to do.

If you cannot access the variables any other way, you can edit
ros_state.kl and ros_relay.kl on your PC, set 'cfg_.checked' to 'TRUE'
in 'check_cfg_()', rebuild and re-upload to your controller (just those
two programs).

You might have to first remove the version that is there and make sure
to delete the .VR file as well. If you run into problems doing that, see
[9].

>> Rundown of steps to get here:
>>
>> - I got the karel driver from
>> https://github.com/gavanderhoorn/fanuc/tree/v611_karel_moveto. I
>> translated all the karel code and transferred it onto the controller. I was
>> then trying to follow step 7 of
>> http://wiki.ros.org/fanuc/Tutorials/hydro/Configuration. I did not
>> have the option of [TYPE]->KAREL Vars. Some googling searching revealed
>> that although I have KAREL Run-Time Env,J539 I don't have KAREL installed
>> on the controller. So I cannot edit the variables from the pendant. So I
>> went and set cfg.checked = TRUE in ros_state.kl and ros_relay.kl. Luckily
>> the defaults worked fine for me. Is there any better way to do this? I can
>> see the variables from FRRobotDemo but I can not change them. PS. I really
>> like that Makefile in fanuc_driver/karel. Much better than using WinOLPC.
>>

>> I'll check the alarm log tomorrow.
>
> The major thing I want to discuss today are some problems I have while
> following [7]. I got to section 2.1 and after hitting Plan, planning
> failed for my robot. Attached is the terminal output. Here is a short video
> https://www.youtube.com/watch?v=b8hJwj721fk&feature=youtu.be showing a
> screen capture of this happening (I had to use youtube because the
> attachment was too big, also it wouldn't let me make it into a link for
> some reason). I get several errors. Can you point me in the right place to
> start debugging?

As you can already see from the RViz visualisation, links 4 and 6 are in
collision in the pose you dragged your robot in (notice the two links
turning red). Clicking 'plan' is essentially useless then, as it is
impossible to find a collision free path if you set the goal state to a
state in which it is in collision.

That being said, those links should not be in collision in that pose, so
I'll take a look. It's probably the shape of the collision mesh of
link_4 that is and issue here.

As a quick work-around, add the following to the
fanuc_lrmate200ib3l.srdf in your moveit config:

<disable_collisions link1="link_4" link2="link_6" reason="Never" />

That makes MoveIt ignore that collision for now, which should be fine,
as it should not be possible for those two links to collide (given the
joint limits on joint 5 and the physical dimensions of the links).

> I was also able to run section 3.1. The path the planner came up with was
> very long and sporadic.

Planners in MoveIt are sampling based, so without any cost function any
path through the robots environment that is free of collisions is
considered equally 'ok'. Some planners come up with better paths though,
try RRTConnect next time.

Constraining the state space of your planning problem (ie: add some
physical boundaries (walls)) should also help.

But without a proper model, no planner will come up with nice plans,
obviously.

[9]
http://wiki.ros.org/fanuc_driver/Troubleshooting#MEMO-159:_Convert_failed_in_PROG

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

On 05/06/15 10:25, G.A. vd. Hoorn - 3ME wrote:
> On 04/06/15 23:42, Lucas Chavez wrote:

[..]

>> The major thing I want to discuss today are some problems I have while
>> following [7]. I got to section 2.1 and after hitting Plan, planning
>> failed for my robot. Attached is the terminal output. Here is a short
>> video
>> https://www.youtube.com/watch?v=b8hJwj721fk&feature=youtu.be showing a
>> screen capture of this happening (I had to use youtube because the
>> attachment was too big, also it wouldn't let me make it into a link for
>> some reason). I get several errors. Can you point me in the right
>> place to start debugging?
>
> As you can already see from the RViz visualisation, links 4 and 6 are in
> collision in the pose you dragged your robot in (notice the two links
> turning red). Clicking 'plan' is essentially useless then, as it is
> impossible to find a collision free path if you set the goal state to a
> state in which it is in collision.
>
> That being said, those links should not be in collision in that pose, so
> I'll take a look. It's probably the shape of the collision mesh of
> link_4 that is and issue here.

Just checked and it is actually the shape of link_4: its collision (and
also its visual) mesh is a convex hull, and it is almost always in
collision with link_6 due to its shape.

> As a quick work-around, add the following to the
> fanuc_lrmate200ib3l.srdf in your moveit config:
>
> <disable_collisions link1="link_4" link2="link_6" reason="Never" />
>
> That makes MoveIt ignore that collision for now, which should be fine,
> as it should not be possible for those two links to collide (given the
> joint limits on joint 5 and the physical dimensions of the links).

Changing the mesh is an option, but I think it makes more sense to
disable the collision in the moveit config. The links cannot physically
collide due to the joint limits, so it should be fine.

Grippers etc should be modelled by their own urdf, so they add geometry
which will be taken into account in collision checking (but only after
you have updated your moveit config of course).


Gijs

[Lucas Chavez]

If you cannot access the variables any other way, you can edit 
ros_state.kl and ros_relay.kl on your PC, set 'cfg_.checked' to 'TRUE' 
in 'check_cfg_()', rebuild and re-upload to your controller (just those 
two programs). 
You might have to first remove the version that is there and make sure 
to delete the .VR file as well. If you run into problems doing that, see 
[9]. 

Right. This is basically the plan I went with. Here is quote of mine about that:

So I went and set cfg.checked = TRUE in ros_state.kl and ros_relay.kl. Luckily the defaults worked fine for me.

I will try deleting the associated .VR files and re-uploading to the controller.

I made the change to my move it config specifying to ignore collisions between links 4 and 6. I then changed to RRTConnectkConfigDefault in the Context tab of Rviz and the planning is executing much better. Thank you :)

Planners in MoveIt are sampling based, so without any cost function any 
path through the robots environment that is free of collisions is 
considered equally 'ok'. Some planners come up with better paths though, 
try RRTConnect next time. 

Currently, I am unsure how to select a planner in the case that I am not using rviz. I think I need to read more to figure out that interface.

 

Constraining the state space of your planning problem (ie: add some 
physical boundaries (walls)) should also help. 

Can you give me a reference of how to do this? I am not sure what the workflow should look like. Do I need a mesh file of a table (for example), and then run the MoveIt wizard, and then the table will be in my environment when I use that outputted config file? 

Next step is to see if this will run on the actual robot. 

 

[Lucas Chavez]

I retranslated ros_relay.kl and ros_state.kl with cfg.checked set to TRUE in each file. To be clear, both .kl files already had cfg.checked set to TRUE I just wanted to double check. I then deleted ros_relay.pc, ros_relay.vr, ros_state.pc, and ros_state.vr in that order using the pendant. I went to copy the .pc files over to the controller and the copy failed. See attached images. I am not sure why it failed. That is where I am now.

As soon as I can get ros_relay and ros_state back onto the controller I should be able to use MoveIt to control the actual robot. 

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

On 12-6-2015 20:29, Lucas Chavez wrote:
>> If you cannot access the variables any other way, you can edit
>> ros_state.kl and ros_relay.kl on your PC, set 'cfg_.checked' to 'TRUE'
>> in 'check_cfg_()', rebuild and re-upload to your controller (just those
>> two programs).
>> You might have to first remove the version that is there and make sure
>> to delete the .VR file as well. If you run into problems doing that, see
>> [9].
>
> Right. This is basically the plan I went with. Here is quote of mine about
> that:
>
>> So I went and set cfg.checked = TRUE in ros_state.kl and ros_relay.kl.
>> Luckily the defaults worked fine for me.
>
> I will try deleting the associated .VR files and re-uploading to the
> controller.
>
> I made the change to my move it config specifying to ignore collisions
> between links 4 and 6. I then changed to RRTConnectkConfigDefault in the
> Context tab of Rviz and the planning is executing much better. Thank you :)
>
>> Planners in MoveIt are sampling based, so without any cost function any
>> path through the robots environment that is free of collisions is
>> considered equally 'ok'. Some planners come up with better paths though,
>> try RRTConnect next time.
>>
> Currently, I am unsure how to select a planner in the case that I am not
> using rviz. I think I need to read more to figure out that interface.

You'll want to use MoveIt's C++ and / or Python API. See the MoveIt site
for tutorials, or any of the 'Using ROS for robotics' and similar books
for that.

Additionally, the ROS-Industrial training exercises should be helpful.
See [10].

>> Constraining the state space of your planning problem (ie: add some
>> physical boundaries (walls)) should also help.
>
> Can you give me a reference of how to do this? I am not sure what the
> workflow should look like. Do I need a mesh file of a table (for example),
> and then run the MoveIt wizard, and then the table will be in my
> environment when I use that outputted config file?

You have two options:

1. Use MoveIt collision objects to model your scene
2. Use URDF to model your scene

For beginners, I'd recommend option 2. See any of the tutorials about
URDF for how this works (see [11] fi).

re: return MoveIt: yes, your workcell urdf (a composite of the 3L xacro
and any workcell geometry) is 'just another robot' (but this time with
geometry describing the surroundings). So you'll have to create a MoveIt
config for it as well.


Gijs


PS: actually, there is an option 3, which would be to use any kind of
sensor to update MoveIt's 'environment server'. This is typically done
using the data from an RGBD sensor (kinect fi), which gets eventually
converted into an Octomap that is used by MoveIt for planning. I think
it is best to first use a static model of your cell, and then, depending
on your needs, move to octomap based collision avoidance.

PPS: [12] provides some more info on how to use the files in
fanuc_lrmate200ib_support to create composite urdfs

[10] http://aeswiki.datasys.swri.edu/rositraining/indigo/Exercises/
[11] http://wiki.ros.org/urdf/Tutorials
[12]
http://wiki.ros.org/Industrial/Tutorials/WorkingWithRosIndustrialRobotSupportPackages

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

On 13-6-2015 0:38, Lucas Chavez wrote:
> I retranslated ros_relay.kl and ros_state.kl with cfg.checked set to TRUE
> in each file. To be clear, both .kl files already had cfg.checked set to
> TRUE I just wanted to double check. I then deleted ros_relay.pc,
> ros_relay.vr, ros_state.pc, and ros_state.vr in that order using the
> pendant. I went to copy the .pc files over to the controller and the copy
> failed. See attached images. I am not sure why it failed. That is where I
> am now.

That sometimes happens. Long story short: easiest is probably just to
remove everything ros-i related from the controller (so all '.pc' files
and their '.vr's). Then upload everything again.

Alternatively you could remove just libssock.(pc|vr) and see if you can
then copy the relay and state programs then. Don't forget to put
libssock.pc back again as well.

[Lucas Chavez]

You'll want to use MoveIt's C++ and / or Python API. See the MoveIt site 
for tutorials, or any of the 'Using ROS for robotics' and similar books 
for that. 
Additionally, the ROS-Industrial training exercises should be helpful. 
See [10]. 

You have two options: 
 1. Use MoveIt collision objects to model your scene 
 2. Use URDF to model your scene 
For beginners, I'd recommend option 2. See any of the tutorials about 
URDF for how this works (see [11] fi). 
re: return MoveIt: yes, your workcell urdf (a composite of the 3L xacro 
and any workcell geometry) is 'just another robot' (but this time with 
geometry describing the surroundings). So you'll have to create a MoveIt 
config for it as well. 

Thank you I will look into all of that.

That sometimes happens. Long story short: easiest is probably just to 
remove everything ros-i related from the controller (so all '.pc' files 
and their '.vr's). Then upload everything again. 

Great. That worked.

I decided to fork my fanuc and fanuc_experimental onto my repository in order to keep track of my work. So now I can finally show you how I modified ros_relay.kl and ros_state.kl: https://github.com/lucasplus/fanuc/commit/6d0373dba93fec41ab37696436c2a248bb3b5239

I feel that I am very close! I am stuck trying to run the 3rd tutorial of http://wiki.ros.org/fanuc/Tutorials/Running. I get "ResourceNotFound: fanuc_lrmate200ib3l_support" I then did a rospack list and sure enough, fanuc_lrmate200ib3l_support isn't there. Please see attached terminal output files. I am sure it involves changing one of the configuration files but I don't know which one. You can check out my fanuc_experimental fork https://github.com/lucasplus/fanuc_experimental. It has the moveit config for my robot. That is the difference right now. 

I know the answer is somewhere in the lr mate 200ic support folder. It is also a robot that has several variants. Like the LR Mate 200ib. I guess the main thing is. I don't know how robot variants are handled. 

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

On 20-6-2015 0:45, Lucas Chavez wrote:
[..]

> I decided to fork my fanuc and fanuc_experimental onto my repository in
> order to keep track of my work. So now I can finally show you how I
> modified ros_relay.kl and ros_state.kl:
> https://github.com/lucasplus/fanuc/commit/6d0373dba93fec41ab37696436c2a248bb3b5239
>
> I feel that I am very close! I am stuck trying to run the 3rd tutorial of
> http://wiki.ros.org/fanuc/Tutorials/Running. I get "ResourceNotFound:
> fanuc_lrmate200ib3l_support" I then did a rospack list and sure enough,
> fanuc_lrmate200ib3l_support isn't there. Please see attached terminal
> output files. I am sure it involves changing one of the configuration files
> but I don't know which one. You can check out my fanuc_experimental fork
> https://github.com/lucasplus/fanuc_experimental. It has the moveit config
> for my robot. That is the difference right now.
>
> I know the answer is somewhere in the lr mate 200ic support folder. It is
> also a robot that has several variants. Like the LR Mate 200ib. I guess the
> main thing is. I don't know how robot variants are handled.

[..]

There is no 'fanuc_lrmate200ib3l_support': the whole idea of the support
pkgs is to avoid having to create them for each and every variant of a
particular manipulator model. In this case, 'fanuc_lrmate200ib_support'
contains files for both the LR Mate 200iB ('base model') and the /3L (a
'variant'). Section 4, from [12] (linked earlier):

"All ROS-Industrial robot support packages contain the following
launch files, **one set per robot variant**"


In your case this means that you should be using the
'robot_state_visualize_lrmate200ib3l.launch' and
'robot_interface_streaming_lrmate200ib3l.launch' files from [13]. Both
when you want to launch things from the command line, as well as when
including them in other launch files, such as
'moveit_planning_execution.launch'.


Gijs

[12]
http://wiki.ros.org/Industrial/Tutorials/WorkingWithRosIndustrialRobotSupportPackages
[13]
https://github.com/ros-industrial/fanuc_experimental/tree/e161c95727887edce32a2ee96ff56f125087be98/fanuc_lrmate200ib_support/launch

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

Also: take a look at some of the other
'moveit_planning_execution.launch' files in any of the Fanuc MoveIt
configuration pkgs. There isn't any magic going on, and you should be
able to figure out what is needed for your 200iB/3L.

[Lucas Chavez]

Ok. Thank you. That helped. I am now able to launch the 3rd tutorial from http://wiki.ros.org/fanuc/Tutorials/Running. You can see the changes I made here: https://github.com/lucasplus/fanuc_experimental/commit/48151431bedf36a977ebfac7187133714ae221a8

Please see attached terminal and pendant output for the next section: I can then move to a new goal point in RViz and then hit plan and execute. The arm starts along the path but stops in the middle. I look at the output on the terminal and see the error "[ERROR] [1435257121.315144910]: Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was 1.918250 seconds). Stopping trajectory."

Do you have any suggestions? 

Should I be changing config/joint_limits.yaml ?

I also believe I am limited because I have only been able to run the demo in T1 mode. I have tried to run the demo in T2 mode, but I get the error "TPF-104 Teach Pendant is disabled"

Lucas

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

On 25-6-2015 20:51, Lucas Chavez wrote:
> Ok. Thank you. That helped. I am now able to launch the 3rd tutorial from
> http://wiki.ros.org/fanuc/Tutorials/Running. You can see the changes I made
> here:
> https://github.com/lucasplus/fanuc_experimental/commit/48151431bedf36a977ebfac7187133714ae221a8
>
> Please see attached terminal and pendant output for the next section: I can
> then move to a new goal point in RViz and then hit plan and execute. The
> arm starts along the path but stops in the middle. I look at the output on
> the terminal and see the error "[ERROR] [1435257121.315144910]: Controller
> is taking too long to execute trajectory (the expected upper bound for the
> trajectory execution was 1.918250 seconds). Stopping trajectory."
>
> Do you have any suggestions?
>
> Should I be changing config/joint_limits.yaml ?

No. See [14].

> I also believe I am limited because I have only been able to run the demo
> in T1 mode. I have tried to run the demo in T2 mode, but I get the error
> "TPF-104 Teach Pendant is disabled"

Are you sure you have set the controller in T2 mode? Does your
controller have the three-way selector switch, or just two?

If it's actually in AUTO, then you should turn the TP OFF. If it's
really in T2, then that error doesn't make sense to me now without more
info.

[14]
http://wiki.ros.org/fanuc_driver/Troubleshooting#Robot_stops_at_seemingly_random_points_during_trajectory_execution

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

On 25-6-2015 20:57, G.A. vd. Hoorn - 3ME wrote:
> On 25-6-2015 20:51, Lucas Chavez wrote:
>> Ok. Thank you. That helped. I am now able to launch the 3rd tutorial from
>> http://wiki.ros.org/fanuc/Tutorials/Running. You can see the changes I
>> made
>> here:
>> https://github.com/lucasplus/fanuc_experimental/commit/48151431bedf36a977ebfac7187133714ae221a8
>>
>>
>> Please see attached terminal and pendant output for the next section:
>> I can
>> then move to a new goal point in RViz and then hit plan and execute. The
>> arm starts along the path but stops in the middle. I look at the
>> output on
>> the terminal and see the error "[ERROR] [1435257121.315144910]:
>> Controller
>> is taking too long to execute trajectory (the expected upper bound for
>> the
>> trajectory execution was 1.918250 seconds). Stopping trajectory."
>>
>> Do you have any suggestions?
>>
>> Should I be changing config/joint_limits.yaml ?
>
> No. See [14].

[..]

Btw, you are getting that error because you're in T1, and then only at
50% override. The faq item I linked shows you how to disable the
execution monitoring.

If you'd really rather keep the execution monitoring enabled, you should
either scale the timeout appropriately (so taking into account override,
maximum joint speeds and T1 vs T2) or scale down max joint velocities in
the 'joint_limits.yaml' file.

There is velocity scaling functionality in MoveIt, but it can only be
accessed by using the C++ (and perhaps Python) interfaces. It is not
exposed in the RViz plugin.


Gijs

[Lucas Chavez]

I am looking into what you replied now. Just wanted to quickly respond to this part:

Are you sure you have set the controller in T2 mode? Does your 
controller have the three-way selector switch, or just two? 

Just the two. I think this means we can not run the ROS.tp program from the pendant in T2 mode. I believe the pendant has to be turned to "off" when in T2 mode which then means I can't start the ROS.tp program.  

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

On 25-6-2015 23:12, Lucas Chavez wrote:
> I am looking into what you replied now. Just wanted to quickly respond to
> this part:
>
>> Are you sure you have set the controller in T2 mode? Does your
>> controller have the three-way selector switch, or just two?
>
> Just the two. I think this means we can not run the ROS.tp program from the
> pendant in T2 mode. I believe the pendant has to be turned to "off" when in
> T2 mode which then means I can't start the ROS.tp program.

[..]

you either have a three-way selector switch, with T1, T2 and AUTO, or a
two-way selector, with T1 and AUTO. I've not heard of a T1, T2 only.
That wouldn't really make sense, as then you cannot use the robot in
production (the operator would continuously have to keep pressing the
deadman).

If you have the robot in AUTO, select the 'ros' program, turn off the
TP, then press the cycle start button on your control cabinet. That
should start it. If not, make sure the robot is not configured to start
some other program by default, or is configured to use PNS or something
like that.

And: make sure you have a safe work environment. In AUTO mode, nothing
safe the e-stop is going to stop the robot.


Gijs

PS: just for my understanding: how much experience do you have with
these robots?

[Lucas Chavez]

This is my first time working with an industrial robotic arm. I have to look up most everything when it comes to Fanuc specific issues. We have a consultant who comes in a few hours a week. He is the one cc'd on these posts. His name is Cliff. He has about 30 years experience with industrial robots. Right after I sent my last post he let me know we simply have T1 and AUTO.

RIght now we are working to run ROS.tp in AUTO mode. It makes sense. We just ran into an error. 

Thanks for your quick responses 

[Lucas Chavez]

Cool. So we got the pendant to run ROS.tp in AUTO mode. We had to set the system variable $remote_type to 0. %remote_type is a member of $remote_cfg

Please see attached photo. We have the error "exec_move err: -1" I read section "3.5 exec_move err: -1" in the troubleshooting guide and I don't believe it is related because our ROS console does not show the messages shown in the troubleshooting guide.

I set the parameter "allowed_execution_duration_scaling" in launch/trajectory_execution.launch to 100. The default was 1.2. And I am still getting the error "Controller is taking too long to execute trajectory" 

It seems that our options are to disable  execution_duration_monitoring or to change the values of the "max_velocity" parameters in config/joint_limits.yaml.

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

On 25-6-2015 23:49, Lucas Chavez wrote:
> This is my first time working with an industrial robotic arm. I have to
> look up most everything when it comes to Fanuc specific issues. We have a
> consultant who comes in a few hours a week. He is the one cc'd on these
> posts. His name is Cliff. He has about 30 years experience with industrial
> robots. Right after I sent my last post he let me know we simply have T1
> and AUTO.

Just to clarify: I did not mean anything by asking you about your
experience. Just wanted to make sure I'm not assuming too much about
what you do and do not know.

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

On 26-6-2015 0:49, Lucas Chavez wrote:
> Cool. So we got the pendant to run ROS.tp in AUTO mode. We had to set the
> system variable $remote_type to 0. %remote_type is a member of $remote_cfg

Ok, good.

> Please see attached photo. We have the error "exec_move err: -1" I read
> section "3.5 exec_move err: -1" in the troubleshooting guide and I don't
> believe it is related because our ROS console does not show the messages
> shown in the troubleshooting guide.

'exec_move err: -1' is really only returned when a traj pt will put the
robot outside its joint limits. Make sure the limits configured on the
controller correspond to those in the xacro macro. This is not something
that can be done at runtime at the moment, so you'll have to check it
manually. Could be that your particular robot was configured with limits
that differ from the defaults.

I can also do it for you if you wish, but you'll have to send me a
backup of your controller.

> I set the parameter "allowed_execution_duration_scaling" in
> launch/trajectory_execution.launch to 100. The default was 1.2. And I am
> still getting the error "Controller is taking too long to execute
> trajectory"

That could be due to the 'exec_move err'.

> It seems that our options are to disable execution_duration_monitoring or
> to change the values of the "max_velocity" parameters in
> config/joint_limits.yaml.

I'd first solve the 'exec_move err'.

Then, just as a test, use rqt_dynamic_reconfigure to change the scaling
parameter _after_ you've started up moveit_planning_execution.launch but
_before_ you plan and execute any motions.

[Lucas Chavez]

Just to clarify: I did not mean anything by asking you about your 
experience. Just wanted to make sure I'm not assuming too much about 
what you do and do not know. 

I wasn't offended. I'm glad asked. It's good to know.

System variable $remote_type resets to 1 when the controller is turned off and on. Would you know how to permanently set that to 0?

In order to debug "exec_move err" and to make sure we have knowledge of how to set ROS software axis limits. I modified joint_limits.yaml https://github.com/lucasplus/fanuc_experimental/commit/d13f5e4e7f1e4953a9b32ff0b651de8d6e620cb4. Also see the attached pendant_axis_limits.jpg. I am assuming joint_limits.yaml wants its values in radians. 

I started ROS on the fanuc in AUTO mode. Ran roslaunch. Starting moving the robot and got WARN messages like "Joint joint_6 is constrained to be above the maximum bounds. Assuming maximum bounds instead." Which I think is a good sign. But I was still getting "Controller is taking too long to execute trajectory" Please see attached launch_output_part.txt and pendant_output.txt.

Then I restarted everything and ran rqt Dynamic Reconfigure before creating any goal points. I changed the value of /move_group/trajectory_execution/allowed_execution_duration from 1.1 to 10. This got rid of most of the "Controller is taking too long to execute trajectory" messages. I then started testing goal points that were farther away. After a while I started to get many "exec_move err" messages on the pendant. Also, the solutions from RRTConnectkConfigDefault started to get less good. Please see rviz_barrel_roll.mov. https://www.dropbox.com/s/pn24zolyo4ldy97/rviz_barrel_roll.mov?dl=0 This resulted in the "Controller is taking too long to execute trajectory" error on the console. 

It seems from rviz_barrel_roll.mov that the planner stopped using the joint limits. 

I am also thinking that I sometimes get "exec_move err" messages because of my conversion of degrees to radians. Maybe I should make the range on the axis limits shorter by one degree and then convert to radians. In order to deal with numeric tolerances. 

 But all in all. It's getting closer. Thanks for your continued help. 

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

On 26-6-2015 22:59, Lucas Chavez wrote:
>> Just to clarify: I did not mean anything by asking you about your
>> experience. Just wanted to make sure I'm not assuming too much about
>> what you do and do not know.
>
> I wasn't offended. I'm glad asked. It's good to know.
>
> System variable $remote_type resets to 1 when the controller is turned off
> and on. Would you know how to permanently set that to 0?

Have you checked the "Prog Select" and "System Config" menus?
Remote/local and Sytem UOP are normally configured through those.

> In order to debug "exec_move err" and to make sure we have knowledge of how
> to set ROS software axis limits. I modified joint_limits.yaml
> https://github.com/lucasplus/fanuc_experimental/commit/d13f5e4e7f1e4953a9b32ff0b651de8d6e620cb4.
> Also see the attached pendant_axis_limits.jpg. I am assuming
> joint_limits.yaml wants its values in radians.

Yes, ROS uses radians for all angles (and SI in general), see REP-103
(Standard Units of Measure and Coordinate Conventions) [15].

> I started ROS on the fanuc in AUTO mode. Ran roslaunch. Starting moving the
> robot and got WARN messages like "Joint joint_6 is constrained to be above
> the maximum bounds. Assuming maximum bounds instead." Which I think is a
> good sign. But I was still getting "Controller is taking too long to
> execute trajectory" Please see attached launch_output_part.txt and
> pendant_output.txt.

The "constrained above the maximum bounds" is not necessarily a "good
sign": it essentially means that you've overridden the joint limit on
that particular axis and made it larger than is what is in the urdf. If
you really have your robot configured that way, that is ok. If not,
you've just told the planner that it is ok to plan outside the normal
joint limits for that joint, which is obviously not a good thing.

> Then I restarted everything and ran rqt Dynamic Reconfigure before creating
> any goal points. I changed the value of
> /move_group/trajectory_execution/allowed_execution_duration from 1.1 to 10.
> This got rid of most of the "Controller is taking too long to execute
> trajectory" messages. I then started testing goal points that were farther
> away. After a while I started to get many "exec_move err" messages on the
> pendant. Also, the solutions from RRTConnectkConfigDefault started to get
> less good. Please see rviz_barrel_roll.mov.
> https://www.dropbox.com/s/pn24zolyo4ldy97/rviz_barrel_roll.mov?dl=0 This
> resulted in the "Controller is taking too long to execute trajectory" error
> on the console.
>
> It seems from rviz_barrel_roll.mov that the planner stopped using the joint
> limits.

What makes you conclude that? joint_4 has more than +/-pi in both
directions, even in your edited joint_limits.yaml file, so that 'barrel
roll' is perfectly valid.

You have to remember that you don't set any constraints on the motion
(other than the beginning and end state): ANY trajectory that is free of
collisions will be valid. There is NO cost function to tell it that this
trajectory is worse than any others.

> I am also thinking that I sometimes get "exec_move err" messages because of
> my conversion of degrees to radians. Maybe I should make the range on the
> axis limits shorter by one degree and then convert to radians. In order to
> deal with numeric tolerances.

Yes, some of the '(min|max)_position' entries you added are indeed
rounded and end up outside the limits set in the urdf. As those in the
urdf are already very close to the physical limits, I'm not surprised
that leads to exec_move errors.

I'd suggest to only override those limits that actually need it (and
then only the bounds that need it). Looking at the commit you linked,
that means: (2, max), (3, min), (5, min & max), (6, min & max). And when
converting, don't round, but floor or truncate the radian values to the
desired nr of decimals.

I'd also suggest you actually don't edit joint_limits.yaml, but update a
local copy of the lrmate200ib3l_macro.xacro, regenerate the urdf and
then rerun the MoveIt Setup Assistant on your pkg (no need to recreate
it, just "Load an existing" one). That should automatically update all
the limits.

If you really want to do everything 'correct', you'd actually not call
your pkg 'fanuc_lrmate200ib3l_moveit_config' anymore, but
'my_lab_fanuc_lrmate200ib3l_moveit_config' or whatever, to indicate for
which particular setup this config pkg is.

Only after you've made these changes can we start to look at what would
cause 'move_exec err' in your specific case, if you still get them.

Also: due to the way the driver currently works, you will always have to
either scale or disable the trajectory execution. We simply cannot get
100% motion performance right now, as we don't have sufficient access to
the motion subsystem on Fanuc controllers.


Gijs

[15] http://www.ros.org/reps/rep-0103.html

[Lucas Chavez]

Gijs,

Very late response. I know. My involvement with the project is currently over. Thanks again so much for all your time and help. I just wanted to respond to some of your responses and also say:

The changes you made so that the karel driver would work with v6 seemed to work well. I am guessing those changes were just an exercise to see if it was possible because they are on your own personal branch. Correct? 

I think I just had configuration issues. Unfortunately, I did not have enough time to properly diagnose them. 

Lucas

On Saturday, June 27, 2015 at 4:59:59 AM UTC-6, gavanderhoorn wrote:

On 26-6-2015 22:59, Lucas Chavez wrote:
>> Just to clarify: I did not mean anything by asking you about your
>> experience. Just wanted to make sure I'm not assuming too much about
>> what you do and do not know.
>
> I wasn't offended. I'm glad asked. It's good to know.
>
> System variable $remote_type resets to 1 when the controller is turned off
> and on. Would you know how to permanently set that to 0?

Have you checked the "Prog Select" and "System Config" menus?
Remote/local and Sytem UOP are normally configured through those.
 

You are right. I made the change through that menu. It worked.

Ok. Good to know. 

> I am also thinking that I sometimes get "exec_move err" messages because of
> my conversion of degrees to radians. Maybe I should make the range on the
> axis limits shorter by one degree and then convert to radians. In order to
> deal with numeric tolerances.

Yes, some of the '(min|max)_position' entries you added are indeed
rounded and end up outside the limits set in the urdf. As those in the
urdf are already very close to the physical limits, I'm not surprised
that leads to exec_move errors.

I'd suggest to only override those limits that actually need it (and
then only the bounds that need it). Looking at the commit you linked,
that means: (2, max), (3, min), (5, min & max), (6, min & max). And when
converting, don't round, but floor or truncate the radian values to the
desired nr of decimals.

I'd also suggest you actually don't edit joint_limits.yaml, but update a
local copy of the lrmate200ib3l_macro.xacro, regenerate the urdf and
then rerun the MoveIt Setup Assistant on your pkg (no need to recreate
it, just "Load an existing" one). That should automatically update all
the limits.

If you really want to do everything 'correct', you'd actually not call
your pkg 'fanuc_lrmate200ib3l_moveit_config' anymore, but
'my_lab_fanuc_lrmate200ib3l_moveit_config' or whatever, to indicate for
which particular setup this config pkg is.

Wish I had the time on the project I needed for those steps. Good recommendations. 

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

On 9-9-2015 19:20, Lucas Chavez wrote:
> Gijs,

Hi Lucas,

> Very late response. I know. My involvement with the project is currently
> over. Thanks again so much for all your time and help. I just wanted to
> respond to some of your responses and also say:

No problem, glad I could help.

> The changes you made so that the karel driver would work with v6 seemed to
> work well. I am guessing those changes were just an exercise to see if it
> was possible because they are on your own personal branch. Correct?

Yes, I kept them there for now because I first wanted to see whether
they worked for you. Without testing on a real robot I'm not going to
integrate them into the main repository.

Some of the changes might end up being merged with the current driver,
so you testing them has been valuable.

> I think I just had configuration issues. Unfortunately, I did not have
> enough time to properly diagnose them.

[..]

That's unfortunate. I hope you've learned some interesting things, and
enjoyed playing with the lr mate.


Gijs