Closed gavanderhoorn closed 2 years ago
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.
Opinions @shaun-edwards, @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.
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).
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.
Right, makes sense.
Thanks for the clarification.
Closing this for now, as it's not going to happen without support from all sides.
I'm re-opening this as part of the discussion over in https://github.com/ros-industrial/ros_industrial_issues/issues/49.
@ted-miller's objection was mostly about not giving the impression that MotoROS can be used without ROS. But https://github.com/ros-industrial/ros_industrial_issues/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 https://github.com/ros-industrial/ros_industrial_issues/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".
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.
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.
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.
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 ?
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.
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 https://github.com/ros-industrial/ros_industrial_issues/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.
ok
Perhaps something to consider: the
MotoPlus
andInform
directories are currently part ofmotoman_driver
, but are not as tightly coupled to it as that arrangement would seem to imply. MotoROS has received multiple updates the past year withoutmotoman_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).