Course Spotlight: Embedded Systems in Robotics

Embedded Systems in Robotics is a project-based course within Northwestern's Master of Science in Robotics (MSR) program that provides students experience with a variety of software tools that could ultimately be valuable for robotics engineers.

The course is one of the mandatory classes for MSR students, and it uses the Robot Operating System (ROS) as an example framework for software architecture. Learning to be comfortable with ROS is one of the course's primary goals.

Students work in groups throughout the quarter to complete software-intensive robotics projects.

Assistant Professor and MSR Associate Director Jarvis Schultz took time to talk more about the course and how it influences the rest of a student's MSR experience.

What role does this class play in helping students develop their foundation in robotics?

The course introduces concepts from many different areas of robotics, including:

• Control
• Path planning
• Localization
• Kinematics
• Computer vision

This helps students better understand what is going on in the world of robotics, and it helps them to frame and understand how other courses they'll take might fit into their career in robotics.

That said, likely the biggest impact of this course is the exposure to — and hands-on experience with — a wide array of tools widely used in robotics software development including the Robot Operating System, Gazebo, CMake, Git, Linux, Python, C++, OpenCV, the Point Cloud Library, and more. Working with a huge variety of tools and figuring out how to assemble them together into a working robotics software stack is something experienced regularly in both industry and academia, and this course provides a first experience and introduction to this challenge.

What do you enjoy most about teaching this course?

There are two primary things I enjoy about this course. First, the fact that the software tools are constantly evolving keeps the course interesting. Bugs that I'll have to help the students work around one year will be completely gone the next year, and sometimes there will be entirely new features to the software that eliminate past challenges.

On the other hand, sometimes packages or tools that used to work don't work anymore due to new incompatibilities or new hardware, or perhaps notes that I will have written one year will be irrelevant or outdated this year. This constant change always keeps me on my toes and requires me to be up-to-date with the latest developments with the tools we use.

The second thing I really enjoy about the course is working with students on the final projects. I intentionally leave the project specifications wide open to give the student teams a chance to be creative and to force them to really think about what is going to make a particular idea they want to implement on a real robot easy or challenging. It's fun for me because sometimes I can see exactly what is going to be a challenge and I can provide solid advice, but sometimes I get it wrong and the teams end up with some strange, hard-to-debug issue that we really have to spend time brainstorming what might be wrong. It's different every year, and it gives me a chance to really get deep into technical issues with the teams.

How important is collaboration for students in the course?

The final projects are all team based, and often the most successful teams are the teams that best handle their time management, communication strategies, and task allocation. I have every team member write a team assessment analyzing how well they thought their team handled these things after the project is over, and often, I think it is a very good lesson for students to see how important these team management strategies really are.

What are some of the routine challenges you see students face in this class?

We cover a wide range of material, and I think that some students feel overwhelmed by the sheer amount of new concepts. This generally is less of a problem for MSR students, because, in our hackathon, I intentionally try to get them early exposure to many of the things they will encounter in my course. I have also recently started doing a glossary quiz during the first week of class where I quiz students on vocabulary associated with many of the tools that we are going to be running into. I find that getting them familiar with the basic terminology right at the beginning leads to more productive conversations and less general confusion throughout the course, and likely leads to a more comfortable overall experience – even though they are often taken aback at a quiz on the second or third day of class.

You've talked about ROS in the past, but for someone who is considering a career in robotics, why is it advantageous to have a ROS background?

An obvious answer is that there are many jobs out there that are specifically looking for ROS experience in a wide array of industries. An easy way to see this is to browse the Jobs section of ROS Discourse. Additionally, we have many MSR alumni who still use ROS every day – see our post with Josh Marino as one example.

A more complicated, but perhaps more useful answer, is that even if someone doesn't end up in a job where ROS is the standard middleware, that company is still solving many of the same challenges that ROS attempts to solve, and providing some sort of solution to those problems. Example challenges that ROS attempts to solve that are likely encountered in other solutions include message logging, data recording, visualization, dependency management, interprocess communication, and more.

The lessons learned when working with ROS are often quite transferable to other solutions to these challenges.