Coming from an academic perspective, in research labs Iâve worked at of course encounter similar difficulties, particularly when onboarding new students with ROS developer workspaces, most notably those with less of a computer science background, as is commonly the case when teaching such a multidisciplinary field as robotics.
For smaller course sizes with a sufficient budget, a simple approach is to allocate the necessary number of lab computers, same as you would for allocating robotic hardware to groups of students. This obviously simplifies the setup for students and comes with a number of other benefits applicable to most CS courses, E.g. well defined and controlled environments, sufficient minimum hardware requirements, ensured compatibility and smooth deployment, etc.
Obviously this trade offs or front loads the system configuration from students and onto instructors, not to mention the added burden of IT administration. Additionally this doesnât scale as well, nore is it as applicable for remote learning curriculums. Lastly, Iâd argue that despite the headaches it can induce, development environment setup remains a valuable portion of the learning process, as its most likely something theyâll have to repeat on their own in their careers, not to mention the added insight and valuable intuition of knowing how and what youâve installed when it comes to eventually debugging projects.
Alternatively, Iâve had a lot of success in introducing colleagues to container based workflows, as it not only simplifies project collaboration, but also the onboarding process in general. Thatâs not to say itâs as easy or intuitive for everyone, particularly those with little experience in linux. While you may then have to allocate lesson time to explain the basics of building and running containers, many of the same challenges you described would still be applicable: such as dual booting linux on student owned hardware or managing Virtual Machines in order to host a linux kernel for containers. Iâll note that docker on windows has come a long way, particularly itâs integration with Microsoftâs WSL, but given ROSâs heavy reliance on networks, any added layer of virtual networking can complicate things.
That being said, while introducing container similarly front loads some complexity at the beginning of a course, I think the rate of return in productivity and collaboration makes it worthwhile. Instructors can essentially codify the lesson environment in the same manner as they would the lesson material, e.g. checking in Dockerfiles inline with each lesson repo, rather than managing gigabytes of VM images outside revision control. For grading and evaluation, the same container environment can also be used for reproducible project demos, such as when the instructor must independently assess project deliverables, or leverage auto-grading via Continuous Integration, as demonstrated in many recent robotic competitions.
With containers, I felt students where less worried about breaking things and spent more time exploring the ROS ecosystem with exotic ideas and dependencies. If the student ends up âborkingâ there debian packages when attempting to install a new deep learning library, no big deal, just respawn the container and try again. When they eventually figure it out, they can just append to the teams project dockerfile so the rest of the group or class can all benefit from any solved logistical issue. Most students will also be taking multiple classes at a time, so being able to isolate a courses lesson environment from others was also helpful in avoiding dependency or system conflicts from other classes or from different projects in the same class. Container images themselves can also be shared directly via any container registry, saving students the time in compiling the world from scratch, such was the case for me personally when I was working with a lot of custom forks of PCL, OpenCV or any other large library that would cause my laptop to catch fire 
.
Finally, much of this complexity can be abstracted away from students using higher level tools like rocker or ADE. E.g: automatically mounting volumes so students donât accidently keep there workspace in an ephemeral container, or automatically mount hardware so the container has access to the same network interfaces and robotic peripherals that are connected to the host OS.
A little dated now, but this goes into more detail about my thoughts on the subject:
