Software Architecture
Author: David Pierce Walker-Howell [email protected]
The software architecture for Perseverance in 2019 has addressed many of the architectural and operational difficulties faced in passed years. In past software architectures for SDSU Mechatronics, the entire system ran as a large multi-threaded application all on the on-board computer. These systems include the Graphical User Interface (GUI), sensor interfacing, navigation control, computer vision, and autonomy. Because these systems were coupled together in a single application, there existed little to no modularity which made it difficult to add new features and let are large team of developers work on the vehicle concurrently. It also induced a large strain on the on-board computer because both the vehicles autonomy system and GUI were combined in a single application.
Therefore in the new software redesign, we have focused on designing a highly modular system where each sub-system can run independently of each other. The architecture developed treats each of the primary systems as an independent node that can communicate with other nodes on a network via message topics. The inspiration for this system is a node based architecture design promoted by the popular Robotic Operating System (ROS). However, instead of using ROS, SDSU Mechatronics has developed a simple python based node networking system called MechOS. This library provides a publisher/subscriber based message communication protocol that allows nodes on a network to communicate with one another simply by specifying the message topics the nodes wants to publish or subscribe to.
Using MechOS allowed for the GUI and autonomous systems to be completely separate applications. The GUI application runs on the users personal computer that is connected to the on-board vehicles computer via Ethernet. The GUI is used during testing to visualize sensor data, observe video stream, tune vehicle configurations, drive remotely, etc. But when the vehicle is in autonomous mode, the GUI is not needed since the on-board autonomy systems are independent.
The on-board system comprises of four main sub-systems: Sensor Driver, Mission Commander, and Vision.
- Sensor Driver: The sensor driver gathers and process sensor data from multiple embedded systems on the vehicle. It communicates with the Attitude Heading Referencing System (AHRS), Doppler Velocity Log (DVL), and pressure depth transducers to localize the position of the vehicle in terms of Roll, Pitch, Yaw, North Pos., East Pos., and Depth.
- Navigation Controller: The navigation controller uses the sensor data from the Sensor Driver and desired position commands from either the Mission Commander or GUI to move the vehicle. A 6 Degree of Freedom PID control system is used to stabilize the vehicle and hold orientations as it navigates autonomously.
- Mission Commander: The Mission Commander is the autonomous system that takes as input a mission description file to execute autonomous missions. It communicates with all the other systems such to determine what commands the vehicle needs to perform in order to complete the high level mission.
- Vision: The Vision systems uses the on-board cameras to obtain information about the environment. Currently, the vision uses the object detection network YOLOv3 Tiny to detect and localize trained objects. Another algorithm called Solve PNP is used to determine the distance, position, and rotation of the detected objects so that the AUV can localize itself in reference to them.
The primary systems of the vehicle communicate using the MechOS library, which you can learn more about by visiting the MechOS Github. The great part about MechOS is the modularity it provides in the system architecture. Each of the core sub-systems (which is typically an executable) of vehicle can be considered as a Node in a Node network. All the nodes in the network are independent systems that can communicate to each other over messaging topics. This is exactly the how the vehicle Perseverance is designed. The Navigation Controller, Sensor Driver, Mission Commander, Vision, and GUI components are separate (isolated) nodes that communicate to each other via a publisher/subscriber network that uses TCP and UDP BSD sockets as the back-end communication layer.
The above diagram shows the primary nodes of the entire vehicle's system and the messages passed between each node via the publisher and subscriber network. If you are familiar with MechOS, then you will know that these nodes don't even need to explicitly know about each other to communicate because the middle-man server mechoscore takes care of registering the nodes when they are started up and forming the socket connections between publishers and subscribers.
The software system of Perseverance contains a lot of configuration parameters that frequently need to be changed, edited, added, or deleted. Some examples of these configuration parameters include PID vaules, USB COM port connections, data save files, etc. Therefore, it made sense to have a centralized parameter file (database) that could collectively store all of these values and have a simple system where any program can "get" or "set" the parameters from the parameter single parameter file. In MechOS, a Parameter Server / Client protocol was built where any python program can "get" or "set" parameters to a single xml file (even if systems are running between multiple machines).