discussion: give motoman_driver its own repository

[gavanderhoorn]

Perhaps something to consider: the MotoPlus and Inform directories are currently part of motoman_driver, but are not as tightly coupled to it as that arrangement would seem to imply. MotoROS has received multiple updates the past year without motoman_driver changing as much.

As MotoROS is used without motoman_driver as well, it might make sense to make this more explicit by giving the MotoROS parts their own repository.

This is really just a discussion issue as I'm not even entirely convinced myself this is something we should do, although it would be more in-line with the way we've started treating robot drivers recently (ie: not necessarily make them part of the repository containing the ROS packages).

[gavanderhoorn]

A quick experiment with git filter-branch ..: gavanderhoorn/yaskawa-motoros.

I would probably not keep the MotoPlus directory if we decide to do this, but just make Inform a sub dir of the repository root.

[gavanderhoorn]

Opinions @shaun-edwards, @ted-miller?

[ted-miller]

I would prefer to keep it in the same repo, but just reorganize the directory structure. Maybe move MotoPlus and Inform folders up to https://github.com/ros-industrial/motoman? Also, I like keeping the Inform folder as a sibling to the MotoPlus folder.

Keeping everything in the same repo helps to ensure that this is viewed a whole package. You need both the PC piece and robot piece for this to function properly. We don't want to give the impression that MotoROS is a standalone ROS node. Although there have been a number of folks using MotoROS as a generic motion interface (outside of ROS), I'd like the emphasis to remain on ROS. Customer support becomes difficult when this is used for other purposes.

[gavanderhoorn]

Keeping everything in the same repo helps to ensure that this is viewed a whole package. You need both the PC piece and robot piece for this to function properly. We don't want to give the impression that MotoROS is a standalone ROS node. Although there have been a number of folks using MotoROS as a generic motion interface (outside of ROS), I'd like the emphasis to remain on ROS. Customer support becomes difficult when this is used for other purposes.

re: need ROS side: true, although one could say that options like the High Speed Ethernet Server also require some 'other pieces' to work. I'm not entirely sure what makes MotoROS different from that.

Maybe move MotoPlus and Inform folders up to https://github.com/ros-industrial/motoman?

I would actually not do this, as all folders at the root of the repository are ROS pkgs, which neither MotoPlus nor Inform are. That would probably confuse users (and it doesn't seem too nice either, from a repository layout perspective).

[ted-miller]

re: need ROS side: true, although one could say that options like the High Speed Ethernet Server also require some 'other pieces' to work. I'm not entirely sure what makes MotoROS different from that.

The complexity of MotoROS is significantly higher than any of our other remote-command interfaces. And it seems to be more popular than stuff like HS EServer (at least in the US). So, it makes support difficult. We get a number of support calls through our traditional customer service channels and it is a challenge to handle them the same way we would handle other interfaces.

Plus, we market our other products entirely different than the ROS interface. It's very easy for someone with no experience to download MotoROS and start tinkering. That is very rare for our other interfaces.

[gavanderhoorn]

Right, makes sense.

Thanks for the clarification.

[gavanderhoorn]

Closing this for now, as it's not going to happen without support from all sides.

[gavanderhoorn]

I'm re-opening this as part of the discussion over in ros-industrial/ros_industrial_issues#49.

@ted-miller's objection was mostly about not giving the impression that MotoROS can be used without ROS. But ros-industrial/ros_industrial_issues#49 actually suggests to seperate all drivers out of their current repositories. For this repository, that would mean taking out motoman_driver: the ROS part and MotoROS. Together.

@ted-miller: could you take a look at ros-industrial/ros_industrial_issues#49 and see whether the rationale provided there is something you can agree with? I realise that most of it deals with issues you don't normally come in contact with, but I hope you can see things from the perspective of the ROS package maintainers here :)

---

So the proposal is now changed to "refactor motoman_driver into its own repository, including both MotoROS and the ROS nodes".

[ted-miller]

To be honest, my previous argument probably isn't valid anymore. The number of people using MotoROS without the ROS environment (or starting with ROS, then evolving into something proprietary while keeping MotoROS) has been steadily increasing. So, the packaging doesn't seem to be discouraging people from using MotoROS.

So... if reorganizing/separating the files makes it easier for others, then I won't object.

[gavanderhoorn]

then evolving into something proprietary while keeping MotoROS

Not sure I'm so happy about this, but I see this (not just with MotoROS actually) quite a bit as well.

Off-topic, but I have the feeling we're reverting to the pre-2007 mindset of NIH which really bugs me (hurray for fragmentation and stagnation of state-of-the-art).

So, the packaging doesn't seem to be discouraging people from using MotoROS.

So... if reorganizing/separating the files makes it easier for others, then I won't object.

Ok. Good to know.

[gavanderhoorn]

I've started looking into this again.

A complicating factor is the unclear history at the beginning of the project (2012), especially during the initial migration from Google Code (SVN) to Github.

I believe I have something which is usable and will share it soon-ish.

The biggest advantage of doing this I see right now is the fact that we can then start cutting Github releases from the MotoROS repository, which would facilitate downloads of both the MotoPlus binary and the Inform jobs: users could just download a .zip directly from Github which would contain the artefacts of interest.

As that is only supported (by Github) based on tags, having MotoROS in its own repository, with the correct tags, makes this possible. Whereas having MotoROS in the same repository as motoman_driver (and the other packages) prevents us from using this as a distribution channel.

[gavanderhoorn]

One thing I would really like is if we could setup some form of CI for MotoROS.

Including Visual Studio projects in such setups is possible and supported here on Github, but seeing as the MotoPlus SDK is needed there are some hurdles.

I have a set of stub headers and source files, which allow compilation with plain CMake, but that would not be my preferred solution.

Would you have any ideas @ted-miller, @EricMarcil ?

[gavanderhoorn]

Just realised there is a potential issue here: ideally, I'd like to split MotoROS and motoman_driver from ros-industrial/motoman.

That would however not result in one additional repository, but two.

Technically it would make sense to do this, as it would support the development of MotoROS as a stand-alone project, motoman_driver as "one of the drivers" to use Yaskawa Motoman robots with ROS, and everything in ros-industrial/motoman would be packages that could be used with motoman_driver, but don't have to be (it's possible other drivers will be created in the future).

From a user experience perspective it's not so clear cut however. Documentation can solve everything, but only to a certain point. We'll have to take this into consideration.

[gavanderhoorn]

I'm going to go ahead and create two additional repositories:

• ros-industrial/motoros
• ros-industrial/motoman_driver

The first would exclusively host MotoROS itself (ie: the MotoPlus application and Inform scripts).

The second would host the ROS side.

Rationale is similar to what is described in ros-industrial/ros_industrial_issues#49, but in this case we also benefit from the fact that cutting releases from ros-industrial/motoros is relatively straightforward, and we can make use of Github's infrastructure and UI for downloads and distribution of those releases.

[ted-miller]

ok