Heya,

This is quite complicated so the first question here is: is it worth it?

• this is more robotics than neuroscience (or an application of
  neuroscience to robotics rather than focussed on understanding the brain)
• the HBP already provides the platform
• the HBP provides professional support
• even the standard ROS stack is currently not easily installable on
  Fedora. When I'd checked last, they still supported *buntu as the official
  distribution.

So, id personally prefer if we allocated our limited resources to
computational neuroscience and then focus on neuroimaging which are more
currently more important fields in neuroscience research. We do not have
the manpower to broaden our focus just yet IMO.

Thoughts?

PS: i worked with the robotics sig to try and bring ROS to fedora, but as
youll see, we didnt exactly succeed.

Edit: TLDR: id say this is currently beyond NeuroFedora's scope :/

Hey Ankur,

I understand your concerns and I would love to learn more of your experience with ROS. How long ago was that and who were you working with? Have you seen how many packages are in stable? I was able to get the everything installed no problem. I see this as an explicit way to get us interacting with the Robotics SIG with a potential deliverable.

I think it is important to see this as an add-on to NEST (albeit a somewhat complicated one). The NeuroFedora packages in this case would be just be NEST and HBP's NRP-scripts. ROS, Gazebo/Gzweb and the other dependencies already have other maintainers.

If I was going to prioritize NeuroFedora packaging for neuroimaging I would definitely put other packaging first (Octave/SPM, AFNI, mrtrix3). I know we have some big holes and limited resources and you are right to keep us on mission. This is only here to represent the opportunities from the interactions with other fedora packagers. Somewhat like working with scitech SIG on packaging Octave/MEX compiliation as a dependency for spm12.

Cheers,

-Morgan

Hey Ankur,

Heya!

(long detailed reply---please bring coffee :coffee: :yum: )

I understand your concerns and I would love to learn more of your experience with ROS. How long ago was that and who were you working with?

I'd worked with Rich and Scott on earlier versions of ROS (I'd used ROS for my masters: https://github.com/sanjayankur31/bionav).

https://admin.fedoraproject.org/accounts/group/view/robotics-sig

Even back then, we'd realised that packaging the ROS stack manually was a no-go. We'd even spent time trying to add the required bits to bloom to get it to generate RPMs for us (it does debs for ubuntu but I've not checked lately)

http://wiki.ros.org/bloom

I'd given up at some point (my fork that tried to generate SCL versions for ROS is still here: https://github.com/sanjayankur31/bloom/tree/fedora), and then the idea became to ensure that we had the bootstrap tools in Fedora to let folks install whatever version of ROS they wanted themselves (since ROS provides multiple parallel releases).

Have you seen how many packages are in stable?

Yes, but you'll notice that in Fedora these are the "bootstrap" ROS packages only (catkin, rosdep and so on) that enable users to install the ROS stack from source---a bit like pip for ROS.

(ins)[asinha@ankur-pc  ~]$ sudo dnf list python*-ros*
Last metadata expiration check: 0:01:02 ago on Thu 15 Aug 2019 08:33:00 BST.
Available Packages
python-rosdep-doc.noarch                                                                                                  0.15.2-1.fc30                                                                                        updates        
python-rosdistro-doc.noarch                                                                                               0.7.4-1.fc30                                                                                         updates        
python-rospkg-doc.noarch                                                                                                  1.1.10-1.fc30                                                                                        updates-testing
python2-rosdep.noarch                                                                                                     0.15.2-1.fc30                                                                                        updates        
python2-rosdistro.noarch                                                                                                  0.7.4-1.fc30                                                                                         updates        
python2-rosinstall.noarch                                                                                                 0.7.8-4.fc30                                                                                         fedora         
python2-rosinstall_generator.noarch                                                                                       0.1.16-1.fc30                                                                                        updates-testing
python2-rosinstall_generator.noarch                                                                                       0.1.16-1.fc30                                                                                        fedora         
python2-rospkg.noarch                                                                                                     1.1.10-1.fc30                                                                                        updates-testing
python3-colcon-ros.noarch                                                                                                 0.3.11-1.fc30                                                                                        updates-testing
python3-colcon-ros-bazel.noarch                                                                                           0.0.1-2.fc30                                                                                         updates        
python3-rosdep.noarch                                                                                                     0.15.2-1.fc30                                                                                        updates        
python3-rosdistro.noarch                                                                                                  0.7.4-1.fc30                                                                                         updates        
python3-rosinstall.noarch                                                                                                 0.7.8-4.fc30                                                                                         fedora         
python3-rosinstall_generator.noarch                                                                                       0.1.16-1.fc30                                                                                        updates-testing
python3-rosinstall_generator.noarch                                                                                       0.1.16-1.fc30                                                                                        fedora         
python3-rospkg.noarch                     

The ROS stack isn't actually in Fedora at all, only these base tools are. They then pull in and install the different components of the whole stack in the right order (which is included in the rosdep metadata files for each component).

I was able to get the everything installed no problem. I see this as an explicit way to get us interacting with the Robotics SIG with a potential deliverable.

Yes, but from source using their version of pip which sorted out all your deps for you and followed whatever paths and standards ROS devs chose. For RPM packaging, all of these components must be packaged and reviewed one by one in the right dependency order, and all of this must follow the Fedora packaging guidelines (ie., no installing to /opt in Fedora: http://www.ros.org/reps/rep-0122.html).

I think it is important to see this as an add-on to NEST (albeit a somewhat complicated one).

That depends---do we know how large the user base for this is? I've not seen a lot of discussion about this on the nest mailing list. (additionally, do we know what happens to neurorobotics etc when the HBP funding closes---in 2020 is it?) So it's in the "cool but maybe not useful" bucket for me at the moment.

The NeuroFedora packages in this case would be just be NEST and HBP's NRP-scripts. ROS, Gazebo/Gzweb and the other dependencies already have other maintainers.

If you mean the full ROS stack here (https://index.ros.org/packages/), for the reasons above, I'd not do it. I is a massive undertaking---best left to the ROS bootstrap tools (that seem to do the trick from what you say) IMO.

If I was going to prioritize NeuroFedora packaging for neuroimaging I would definitely put other packaging first (Octave/SPM, AFNI, mrtrix3).

Yes--exactly. I was going to propose at our next meeting that we focus on neuroimaging as "phase 2" now that we have a majority of comp-neuro tools included. This is because

• neuroimaging forms a very large chunk (probably the largest?) of neuroscience---probably our largest use case
• neuroimaging consists of a large proportion of researchers who come from fields other than computing. So, I think there's a more urgent requirement for a ready-to-use solution (the same reason neurodebian exists basically).

Additionally:

• unlike ROS which provides these pip like tools that (at least in theory) let one install the stack and manage dependencies, the neuroimaging tools are quite complex and require knowhow of how to build tools and dependencies from source. There's also already the maintained and supported HBP neurorobotics platform for people to use.

I know we have some big holes and limited resources and you are right to keep us on mission. This is only here to represent the opportunities from the interactions with other fedora packagers.

Sure, my note here is meant to be informative to someone looking to package software for us. The majority of the tools in our queue are isolated tools, so it's OK for any team member to randomly pick one to work on. When it comes to ROS, though, it's a whole stack that requires considerable effort. So I want to make sure we have these discussions that serve to inform others of the complexity of these tasks.

Somewhat like working with scitech SIG on packaging Octave/MEX compiliation as a dependency for spm12.

I already have a WIP spec for spm here.

https://github.com/sanjayankur31/rpm-specs/tree/spm12

We were working on it sometime back when we learned that it needs a later version of octave and we've not looked at it since. This is the kind of thing I would like to prioritise as part of the neuroimaging phase.

Summary:

IMO, based on our resources and the neuroscience userbase, I'd say our resources would be best used on consolidation of our comp-neuro packages and then on neuroimaging. The HBP neurorobotics platform is far too complicated and requires far too much work with possibly little return. Specifically, I'd leave ROS be as it is where Fedora includes the bootstrap tools and users install it. (I would not look into packaging ROS at all)

This ticket has been migrated to the forgejo instance. Please find the new ticket here
https://forge.fedoraproject.org/neuro/NeuroFedora//issues/272