Software Architecture Document for Telerobotics

The First Three Days

Hi! Last couple of days were quite hectic. I am still getting used to the 7-hours a day schedule of GSoC. But the good thing about GSoC is you can adjust the programming schedule according to your own convenience which is one more reason which takes it a notch above other summer coding programs. But I am devoting about 10 hours every day in these initial days to ensure I am well-positioned with respect to my timeline and also keep learning stuff on the go.

Rants aside, I recently completed the first draft of the Software Architecture Document for my project.

Software Architecture Document

Software Architecture Document (quite funnily abbreviated as SAD) is an important (read very) piece of information which entails and ensures what a software project is going to look like when it is built and shipped. I must thank the Italian Mars Society for giving me the much-needed push into the world of Open Source Software Engineering.

Architecture of any program, especially open-source programs, as described in the excellent book Architecture of Open Source Applications describes software in terms of different layers of abstraction components, depending on who wants to look and improve upon it. Open source applications are a product of efforts of multiple people working on different aspects of a project together. To facilitate effective and non-redundant collaboration with proper version control, a software architecture document comes in handy.

To put it in one line -

SAD ensures all developers, testers, and users are on the same page.

SAD for Telerobotics Application

Take my Telerobotics application for instance. It is made up of three distinct features or functional requirements -

• Mapping Human body-tracking information to rover motion instructions
• Allowing real-time streaming of the rover’s stereo camera-feed to the ERAS application
• Providing an Augmented reality interface obtained from the processing the rover sensor data

Although I am the only developer working on these aspects currently, I must ensure that the application is in a well-maintained state throughout the life of the project. I must also ensure that a developer with skills in Robotics gets relevant information to the Robotics subsystem of the application (ROS knowledge). I must separate the concerns of a Network Communications developer from the user (the astronaut) while working on Real-time streaming from the rover to the Head Mounted Virtual Reality device.

While the features describe the expected behaviour of the software system, they require a lot of background machinery which is essential for operation but not relevant for exposing to the end-user. These are non-functional requirements. To give an example, Robotics Operating System is used to manouver the Husky robot around. But the astronaut or the software system need not be concerned that robot communication, control, and command (C3 architecture) takes place using ROS or other robot platforms like YARP or Player/Stage.

Non-functional requirements in turn are quite important for satisfying the performance requirements of the software system. For instance, the Real-time streaming protocol (RTSP) that I’ll be working with soon directly impacts the performance requirement of Hard-Real Time streaming support.

The Software Architecture Document is generic in that it keeps in mind the evolving technology that may be used to cater to the application in focus. For instance, the Unmanned Ground Vehicle currently being considered is the Husky rover. It is my responsibilty to ensure that the logical layers are independent of the robot being used. The software should be extensible easily to a future ground vehicle that may use an altogether different control architecture than ROS.

Finally, SAD is practical. It describes the timeline of development of the features.

My experience with SADs

Working on the SAD has been an immensely edifying experience for me for several reasons -

1. My first foray into Software Engineering literature.
2. Learning reStructuredText as the documentation tool for SAD.
3. Appreciating how finely ingrained software-engineering principles are with Programming Language design. For instance, the sections of a SAD directly imbue the features of Object Oriented Programming (abstraction, encapsulation, separation of concern) and Functional Programming (Side effects, Higher-order functions).

Links to the document

If you are interested, the link to my software architecture document source is this.

The documentation on readthedocs can be found here.

Until my next post on my first week of coding.

Ciao!