-
Notifications
You must be signed in to change notification settings - Fork 1
ROS and Wallframe
We chose the Robot Operating System (ROS) for a base framework for WallFrame. (Click here for a good introduction. ROS was designed primarily for robotic systems where several disperate components (such as cameras, motor controllers or laser scanners) needed to be connected to one another in a modular manner.
Sound familiar? This kind of functionality is exactly what we need for a modular application management system for display walls.
IMPORTANT !! It is essential that you understand ROS. Please... do not continue unless you have gone throught the ROS Tutorials and understand words like topic, parameter, TF, service and launch.
Here is how we use ROS to make WallFrame work:
All of the core modules in WallFrame are ROS modules. Modules communicate with one another in an asynchronous manner using the topic publisher and subscriber design patter. This means that the firmware that talks to my depth camera (Kinect, Xtion, ect) can publish the positions of a users joints in 3D to any other module that listens. Similarly, if I have a user manager that is detecting gestures from that data, I can now publish the gesture events out to applications. Everything is its own process; no need to recompile or share libraries.
The packages we previously discussed in the overview, namely wallframe_core, wallframe_user, wallframe_tracker, and wallframe_msgs, are all ROS packages. As well, _each WallFrame Application is a ROS package complete with its own cmake file, manifest, launch files and source. This makes it very clean to manage different applications, as they are all compartmentalized.
Parameters are used extensively in WallFrame, to specify user limits, screen rendering regions, thresholds and lots of other stuff. By setting a parameter on the server under the namespace /wallframe/~, it will be accessible to any WallFrame module or application.
As you learned in the ROS tutorials, launch files allow you to bring up multiple executables or nodes at the same time, specify parameters, and do other cool stuff. We use launch files to fire up the core WallFrame modules, set the WallFrame parameters, and each wall application has its own launch file, where you specify app specific parameters, or multiple components inside that app, should you choose to do so. This means that you could have more than one application in a single package, but we discourage this.
Next: [A Sample Application](Sample Application)