anchor.diff:  end
   ----
   
  -The implementation is unfortunately closed-source, but be were able to get an idea of the internals by looking at the MATLAB tooolbox files as well as the compiled Java bytecode. As far as we could tell they built a small Java library that wrapped RosJava functionality in order to provide an interface that was easier to call from MATLAB. Most of the actual logic seemed to be implemented in MATLAB code, but we also found several calls to various Java libraries for problems that would have been difficult to implement in pure MATLAB, e.g., listing networking interfaces or doing in-memory decompression of images.
  +Due to the implementation being closed-source, we were only able to look at the public toolbox files as well as the compiled Java bytecode. As far as we could tell they built a small Java library that wrapped RosJava functionality in order to provide an interface that was easier to call from MATLAB. Most of the actual logic seemed to be implemented in MATLAB code, but we also found several calls to various Java libraries for problems that would have been difficult to implement in pure MATLAB, e.g., listing networking interfaces or doing in-memory decompression of images.
   
   Overall, we found that the ROS support toolbox looked very nice and was a great example of how seamless external languages could be integrated with MATLAB. We also really liked that they offered a way to load log files (rosbags).
   
  
positive.code: 
  == The Need for External Languages
  
  The main limitation when trying to use MATLAB to interface with hardware is that its scripting language is fundamentally single threaded. It has been designed to allow non-programmers to do complex math operations without needing to worry about programming concepts like multi-threading or synchronization.
  
  This poses a problem for real-time control of hardware because all communication is forced to happen synchronously in the main thread. For example, if a control loop runs at 100Hz and it takes a message ~8ms for a round-trip, the main thread ends up wasting 80% of the available time budget waiting for a response without doing any actual work.
  
  
negative.code:  */
  public class MessageAggregator implements LCMSubscriber {
  
      /**
       * Value type that combines multiple return arguments
       */
      public static class Message {
      
          final public byte[] data; // raw bytes
          final public String channel; // source channel name
          
          public Message(String channel_, byte[] data_) {
              data = data_;
  