search

ipa320 / cob_robots

www.care-o-bot.org
Apache License 2.0
68 stars 133 forks source link

delete EOL robots and EOL packages #793

Open floweisshardt opened 4 years ago

floweisshardt commented 4 years ago

EOL robot candidates are:

remove those robots from

EOL package candidates are:

@ipa320 @ipa-rmb @ipa-fog @ipa-jba @ipa-fez @ipa-srd @ipa-nhg @ipa-mdl @ipa-jcl @ulrichreiser any objections?

fmessmer commented 4 years ago

I agree with removing robots and its configs/launch files also, removing urdf/xacro components of those robots seems fine dependency entries in package.xml which are not needed anymore after removing launch files can be removed, too

for EOL packages in e.g. cob_control and cob_driver etc. I would simply add a CATKIN_IGNORE rather than deleting or moving them...

all that should be done in a coordinated PR set merged right after the next release/tagging (this release/tag set is the version until those robots were supported)...re-releasing/re-tagging right afterwards again to not mix anything other than "removing ballast" into the CHANGELOG...

jabbenseth commented 4 years ago

currently we are running raw3-3 as one of our main robots so imho it is not eol. afaik it uses no cob_driver/control components different from current cob4 robots.

Regarding the raw_description package: there is a raw4 incoming. The merge requests was stale but it looks like we will find/need some time to work on raw4 soon

floweisshardt commented 4 years ago

currently we are running raw3-3 as one of our main robots so imho it is not eol. afaik it uses no cob_driver/control components different from current cob4 robots.

ok, I'll remove raw3-3 from the list of deletable robots.

floweisshardt commented 4 years ago

Regarding the raw_description package: there is a raw4 incoming. The merge requests was stale but it looks like we will find/need some time to work on raw4 soon

then let's keep raw_description. I remove it from the list of deletable packages.

jabbenseth commented 4 years ago

we had a short internal discussion. Right now it looks like we are moving the "rob@work" specific files to our own repository so you don't have to maintain/take over some responsibilities for the rob@work line of robots. This doesn't mean we are not using e.g. cob_driver, but it is likely that we will move all r@w specific stuff to us (in an upcoming PR)

fmessmer commented 4 years ago

if you ask me, I'm still in favor of not removing what is currently working....but remove it once it's broken - to save the effort of fixing it...

as to raw stuff: raw stuff (as one of several) currently prevents a proper melodic release of cob_robots due to the outdated dependency to universal_robots forraw3-1` which is not-maintained anymore anyway

so if you'd like to "move" raw stuff (description, config and launch files), that'd be ok for me to remove those things from cob_X repos :point_right: that would also mean that IPA takes over support for sold raw's?

but all the other nodes listed above, i.e. "EOL package candidates" - even if unused by supported robots - could remain as long as they are not breaking anything...they have been provided to the ROS community and we do not necessarily know whether anybody else uses them...

jabbenseth commented 4 years ago

One of the points I'm currently running in is, that cob_bringup supplies bringups for a whole load of heterogeneus robots (cob4, raw3 short, raw3 long with arm, raw mini, maybe someday raw4) which all require different dependencies (nothing needs the "cob_mecanum_controller" except the raw-mini, universal robots is only needed for raw3-1 ...).

I wanted to do a minimal install package to install on raw-mini basically where only max. 10% of the (transitive) dependencies of cob_bringup, cob_hardware_config... are actually needed. This didn't work because for example the universal robot stuff --> I created another package "raw_mini_bringup" where I hand-picked dependencies and copied files from cob_bringup so I don't have to depend on cob_bringup. imho a common package is reasonable for homogeneus robots but for heterogeneous robots it adds a lot of overhead. The same is true for cob4 which (I assume) is melodic compatible by now, but since raw3-1 is not you cannot move forward until raw3-1 is fixed. so your options are to declare raw3-1 EOL or being stuck on kinetic forever. Splitting up Repostories comes with downsides but allows raw3-1 to be eol without impacting any other robot or needing work (like remove the universal robot driver) which will never be used (since tbh it is probably still running indigo).

Additionally we (ipa) build up a new robot which you never see/hear of until a bunch of random PRs pop up where some mixups happen (like just recently raw-mini != raw4)..

floweisshardt commented 4 years ago

imho a common package is reasonable for homogeneus robots but for heterogeneous robots it adds a lot of overhead.

I compleetly agree with @ipa-jba. This is exaclty the reason why I started the discussion in this issue. Following @ipa-jba statements it would be best to keep cob_robots only for Care-O-bot 4 robots and have a separate raw_robots repository where all rob@work related launch files and dependencies are moved. If we agree to that, it should be ok to remove the listed robots and packages above (https://github.com/ipa320/cob_robots/issues/793#issue-551551457).

destogl commented 4 years ago

Hi, I would appreciate not to remove raw3-5 sine we are using it actively. I agree to move it to raw specific repos, but I would really appropriate to keep it in the repos with other dependencies on your packages we are using.

Thanks for considering this!

floweisshardt commented 3 years ago

@ipa-jba we'd like to takeup this issue again. Did you move raw robots to a standalone repo in the meanwhile?

jabbenseth commented 3 years ago

unfortunately only the raw minis, but I right now I don't see a reason why this should stop you from cleaning up. maybe push a tag, but I will just note down the commit sha and keep my branches and stuff.

floweisshardt commented 3 years ago

@ipa-jba thanks. Sure, we'll create tags of all repos with the latest version which supports EOL raws/cob3s/cob4s.