Software Engineering practises

Summary

Project Fezzik utilized multiple tools and methodologies to support the software engineering process throughout the project. In this section, we briefly want to documment these as an inspiration for further groups to take advantage of these practises and to improve them.

Attention

Software Engineering Practises are important! You should not neglect them. For example, if project Fezzik would not have prototyped their product in multiple iterations, we would probably not have achieved our goal. Prototyping is one of the key practises in Robotics - never build a large segment of code until you haven’t tested the smallest possible part of it.

In the following, we briefly list and explain the software engineering practises we have used, focussing on those relevant from a technical point of view:

  • Rapid Prototyping: Like no other methodology, Rapid prototyping is key to robotics. You must build something quickly and then test it out right away. In Robotics, often the key challenge is to make it work at all rather than in a beautiful way. For each component, we on average had to build 4-5 prototypes until we found a solution that worked in a sufficient way. Keep this in mind - and embrace failure! :-)
  • Slack communication: Besides our Whats App communication for organizational purposes, team Fezzik used Slack as their main communication software for technical discussions. We highly encourage you to do so, too. The main advantage is that slack allows to open topic-oriented channels, e.g. one for #Scrum, one for #GUI and so forth. This way, you do not lose track about the discussions going on.
  • Asana Perhaps our most feature-rich tool was Asana. Asana is a web-based project management application where a team can track projects, assignments, and deadlines, adding tasks and generating reports as necessary. This was most helpful in getting organised early on, and we used a Kanban board method to mark what needed to be done in a given sprint.
  • Git We used Git [5] as our primary version control system. Working with multiple machines, sometimes without access to the Internet, a distributed version control system was our obvious choice. We hosted our Git repository with Gitlab. As a team, we made sure to follow best practices for version control throughout the project. This meant we began a work session with a git fetch and a git merge, and we always ended with an in- formative git commit and a git push. We built our Git repository around our root ROS workspace, which we called fezzik-project. We describe the details of ROS in Section 5. For now, the main idea is that separate software modules (often aligned with separate components) live in independent subdirectories called packages. Our already modular approach to the project made it easy to create separable feature branches. When a subcomponent was complete or needed to be used by some other component, we could merge back.

Note

For further details on our testing procedure, please be referred to our report where we discuss our three ways of testing extensively.