Deep into modification of ROSJava. Removing google proprietary collection classes and assertion framework to use native Java in attempt to get bytecode down for RPi. Chopped out all the benchmarking and test junk thats not essential to runtime.  I have determined that the main areas to use the BigSack instead of the transient collections are the Parameter Server and the main message queue. These mods will give ROS something it needs that other message busses tout: durability. Advantages? Not 'lost work', more immediate resumption of tasks after reboot. Forensic analysis of data traffic (without ROSBagging). More importantly, the option of using those messages in realtime and offline sensor fusion.

The primary goal is to keep this 'open' and 'connected' and provide a mechanism to use whatever interesting advances arise in conjuntion with other ROS enabled platforms. How cool would it be to drop this code into say, an Atlas robot or a AUV or UAV and have it function right off? It seems that exposing the entire forked ROS runtime behind a service node and using that to interface other ROS networks would allow the capabilities of the forked master and parameter server to be used by ROS networks that already provide other-than-client services. 

ToDo: Research multiple masters, bridging, foreign relay:

http://www.ri.cmu.edu/education/McEachernRISSposter.pdf