How have the software engineers settled into the project?

Since the start of the spring semester of 2023, the rover team got six new team members. They are not electrical or mechanical engineering students but computer science students. Unlike the existing team members, they are also part-time students. So they work at least 50% of their time in a company. This provides a benefit because they have much experience working on projects. These six software engineers were given the tasks to create, manage and improve the software and environment of the rover setup. What challenges did the software engineers face, and how does this project differ from the software projects they are used to?

The first few weeks were challenging for us. It was less because of the tasks provided to us but more due to the organization and coordination, or lack thereof with the students from different majors. The project management methods differ greatly between software development and mechanical engineering. In software development nowadays, you usually have a fixed timespan to finish a prioritized list of tasks, goals, phases, etc. In the rover project, however, we had to be more flexible because the importance of a task could change from one week to the next. After the first few weeks, we could overcome this challenge and prioritize our tasks properly in coordination with the other students.

The user interface is one of the tasks where we started from scratch, seeing that the team had previously worked with terminal windows and SSH sessions to control the rover at the ERC. Therefore, the first challenge was finding an appropriate technology to help us implement a simple yet capable Mission Control Center for managing and monitoring our rover.

Quite early in the decision process, we stumbled upon NASA’s Open Mission Control Technologies (Open MCT), an “open source and web-based mission control framework for data visualization on desktop and mobile devices.” Open MCT is designed for spacecraft and rover missions and provides a plugin system with many existing plugins and the opportunity to create your plugins. Hence we found the perfect fit for our UI and started implementing our first views and plugins in Open MCT.

One of the biggest challenges was to understand how ROS2 works. ROS stands for Robot Operating System and is an open-source, meta-operating system for robots. It provides a set of software libraries and tools that help developers build robot applications. Applying the complex configurations required for setting up ROS on MacOS and Windows was a significant challenge, particularly given the contrast with the more direct experience on Ubuntu.

Initially, integrating ROS with a power distribution board (PDB) was tedious due to unclear requirements. However, with improved communication within the team, we overcame this challenge and ensured a smooth and successful operation. The same goes for the Drivetrain, as it had to be refactored a lot. At first, it needed to be clarified what refactoring was necessary. But after some time, the requirements became more precise, and the refactoring could be done properly. A so-called node controls these two tasks. Sidenote: A node is an entity in ROS that can communicate with other nodes.

Another big challenge was the automated building and deployment of our nodes. Previously, we just pulled the code from GitLab, leading to a big mess. Finally, we decided to containerize all nodes with Docker. It took a long time to figure out the best way to containerize and deploy our nodes due to their dependencies. After much trial and error, we managed to have a clean CI/CD pipeline, which has so far worked very well. It also saved us a lot of headaches (although figuring it out caused a lot of headaches too 🙂 ).

As development progressed, we had to figure out how to connect Open MCT with the rover to control the PDB, Drivetrain, and get data back from those two components. We knew the previous team had already created a WebSocket node (ws_node). So, we decided to use this node to connect the UI with the rover. But later, we discovered that ROS provides its version of a WebSocket node, called rosbridge.

There are a lot of benefits in using rosbridge over our custom ws_node. One significant advantage is that we don’t have to manage it ourselves. Another benefit is that the communication between Open MCT and our nodes is much easier thanks to roslibjs, a JavaScript library that directly integrates and communicates with rosbridge.

In future blog posts, we will write more about ROS, the communication between two nodes (node <–> node), OpenMCT and the difference between the rosbridge and our ws_node.

Stay tuned!