The Bridge Backbone
The Bridge Backbone
All software that runs on the bridge can be categorized as Backbone or Content with few exceptions.
Content are programs running on the bridge that are visible to the viewer standing in the 5th floor hallway. They are meant to be viewed and interacted with by the viewer. More information concerning content can be found elsewhere in the Software section of this Wiki.
The Bridge Backbone is the core system that manages all the hardware on the bridge and runs all the content on the bridge. It is a modular system of programs that work together to give the bridge its functionality. It is often refereed to as just "the backbone".
Backbone 1.0 - Originally the backbone was written as a series of Autoit scripts so that Steve, who is very confident and versed in Autoit, would have an easier time managing the bridge. Development was started and successful in managing many aspects of individual stations. Soon, however, it was discovered that Autoit would not suffice for the complex communications that would be needed between the stations. PSTools was then introduced into the backbone to allow Autoit scripts to start programs on other machines. Again success was found, however, we found a consistent three second lag in across station communications that we knew would not allow the backbone to have the a proper response time to system requests. At this point the Autoit backbone was abandoned.
Backbone 2.0 - At the time, Panda 3D was the game engine of choice for the ETC - the backbone was re-written from scratch in Python using Panda 3D where needed. Python is a powerful and flexible language. The strengths of Python and Panda3D fit well with the needs of managing this type of complex system. Success was found and the backbone moved forward. One of the greatest strengths of the two was the fact that Python is compiled at run time. This allows us to easily change code right on the bridge. It is very easy to develop with and debug with during run time. Small changes do not require the whole system to have to be re-built. While Python is slower and less efficient than languages such as the C family, the bridge is not a true space station and no lives are on the line. Also Python handles the loading of resources at run time extremely well. This means that we can change what resources, or content, the system uses without having to recompile the system. The modular system allowed the backbone to be developed in pieces over time. The needs of the bridge were prioritized and the system built accordingly. This allowed us to get front facing buttons controls in quickly and less important sound controls in later.
- The modules are written in Python utilizing some functionality from the Panda 3D game engine library.
- They communicate with each other using OSC Networking protocol.
- PSTools is used to allow modules on one machine to start programs on other machines.
Backbone 3.0? - When the ETC switched over from using the Panda3D game engine to the Unity 3D game engine there was a push to make the bridge utilize Unity only and drop Panda. Whenever a new tool comes to the playing field there is a certain time were anything that uses the old tool is deemed bad. Due-diligence to the possibly of switching to Unity was researched and ultimately rejected. While Unity 3D is far superior to Panda 3D in so many ways it would have actually been harder to develop the backbone in Unity. Also, it doesn't handle dynamic loading of resources well and it would be difficult to develop and debug on the bridge. What little gains would have been achieved did not out way the loss of time in scratching Backbone 2.0 and starting over again.
Very little of the backbone is actually visible from the viewer standing in the 5th floor hallway but without it nothing would run. Before the backbone was created each bridge station just ran visible content. It would take two people about one hour to start all the content and arrange their windows to match the projection holes within the surface of the bridge stations. The Bridge Team knew from the beginning that a backbone would be needed to automate and manage the bridge but it took some time to develop and build it.
Today the backbone runs on the bridge 24/7 and greatly reduces the amount of human intervention needed to maintain the systems. Every morning it reboots all the machines to ensure peek efficiency. It starts every bridge machine, communicates with its hardware, begins content, properly sizes and positions content, handles communication between hardware and content, and turns certain pieces of hardware off at night to lengthen their longevity. It provides humans with a simple interface allowing them to easily control the bridge from one station.
The backbone is organized across several folders on the bridge machines. Each machine's folder structure is setup the same way with a few exceptions.
On the bridge machines, all bridge programs, with few exceptions, exist in the C:\Bridge folder. This folder is updated and maintained through the sync process that mirrors its content with the files found in the bridge-sync$ server folders.
- audio - all audio files that are used for the general bridge ambiance. They are sorted in folders based on their purpose.
- Buttons - all files used by the Button Manager to control the Phidget hardware.
- Content - the menu system and all content that runs on the station.
- lighting - on Bridge0 only, all files used by the Lighting Manager to control the lighting hardware.
- sb-system - the hub of the backbone, all the files used by the Bridge Manager, the Station Manager, and the Helm Control.
- shows - content that runs across the entire bridge at once and is meant to be a show piece.
- test_apps - a temp file area used when testing systems or content on the bridge that is not yet ready for full deploy.
- Touch - all files used by the Touch Manager.
- Viewport - all files used by Viewport to display movies across the six tv screens and all the actual movie files that are to be displayed.
- Bridge Manager
- Station Manager
- Button Manager
- Touch Manager
- Lighting Controller
- Audio Controller
Flowchart - What backbone program starts what other program: