Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

delete EOL robots and EOL packages #793

Open
2 of 24 tasks
floweisshardt opened this issue Jan 17, 2020 · 12 comments
Open
2 of 24 tasks

delete EOL robots and EOL packages #793

floweisshardt opened this issue Jan 17, 2020 · 12 comments
Assignees

Comments

@floweisshardt
Copy link
Member

floweisshardt commented Jan 17, 2020

EOL robot candidates are:

  • raw3-1 👉 universal stuff definitely needs to be removed...ros_industrial/universal_robots is no longer supported as UniveralRobot is now officially involved...
  • raw3-3 still in use at IPA
  • raw3-5
  • cob4-3 (MLR)
  • cob4-4 (MLR)
  • cob4-6 (MLR)
  • cob4-10 (T-LABS)

remove those robots from

  • cob_supported_robots
  • cob_bringup
  • cob_hardware_config
  • cob_default_robot_config
  • cob_calibration_data
  • cob_navigation_config
  • cob_moveit_config

EOL package candidates are:

  • not used by any robot
    • cob_utilities
    • cob_generic_can
    • cob_canopen_motor
    • cob_base_drive_chain
    • cob_undercarriage_ctrl
    • cob_camera_sensors
    • cob_relayboard
  • just used by EOL robots
    • cob_sick_lms1xx (raw3-5)
    • raw_description (raw3-1, raw3-3, raw3-5) raw3-3 is still in use by IPA
      remove those packages and corresponding launch files from
  • cob_bringup

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

@fmessmer
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member

fmessmer commented Feb 5, 2020

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 for raw3-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
👉 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
Copy link
Contributor

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
Copy link
Member Author

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 (#793 (comment)).

@destogl
Copy link
Contributor

destogl commented Feb 18, 2020

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
Copy link
Member Author

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

@jabbenseth
Copy link
Contributor

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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants