Software Overview


Software Architecture
The Software Architecture of Bumblebee is based on the Robot Operating System (ROS) Software Framework from Willow Garage which encompasses the underlying messaging infrastructure for inter-process communications in our distributed system.



The basic unit in ROS is a single node which is a process within itself. ROS offers two key forms of distributed messaging, the concept of Topics which is essentially data streaming over TCP or UDP, and the concept of Services which is an XML-RPC request-response call. Topics were used where real time data updates were required for real time processing and Services were used for one time state updates or to trigger transitions in the system.

BBAUV’s Software Architecture comprises of two parts:

– A High level Architecture where most of the vision processing and high level Artificial Intelligence exists in performing object recognition, motion control and task completion.

– A Low level Architecture where the core sensor and actuator drivers are connected to a low level Controller which is responsible for vehicle locomotion and environmental sensing.

Locomotion and navigation within the AUV were achieved with the use of an Action Server and Action Clients based on the actionlib API from ROS. The establishment of an action server allowed for nodes to perform actuation across processes. In addition this made distributed control of the vehicle over the network possible since connection to an Action Server was established over TCP/IP.

The Action Client and Action Server act as the bridge between the High level and Low level Architecture in our Software systems.




A shared memory model between nodes called the Parameter Server was also utilized for the storage and retrieval of global shared parameters. Local parameters within each node were either statically configured upon initialisation as Private Parameters or were dynamically configured with the dynamic reconfigure API and was generally heavily utilised for the various mission requirement. Each node would spawn a dynamic reconfigure server which handled calls from the dynamic reconfigure gui client (also part of the ROS framework) as and when changes were triggered by the user to each parameter.  The ability to dynamically reconfigure parameters on the fly proved to be crucial for us.

Finite State Machine Design


 The Smach State Machines API was used in the high level software design for the mission planner and task node interactions.  Each node has a few generalised states as illustrated in the diagram above. Inter-nodal communication is achieved with ROS Services. Inter-nodal communication consists of the following four generalised state triggers: Task start, Task search completed, Task completed and Task abort. This structured communication mechanism coupled with our Finite State Machines design provided strong software foundations for a real time system.


Finally within each node multi-threaded ROS callbacks were used extensively for non-blocking reads or concurrency. ROS’s multi-process and multi-threaded framework coupled with the multi-core processor of our quad-core Single Board Computer enabled us to push the software capabilities of Bumblebee further.

The core of the software was written in C++ for the low level drivers and controllers and Python for most of the Computer Vision tasks and High level Artificial Intelligence.

Operating System


The main operating system of choice for Bumblebee was Ubuntu 12.04, Precise Pangolin a variant of the Linux Kernel. Ubuntu was selected for full compatibility with ROS.