anchor.diff:  * The generated Java messages handled the binary encoding and exposed fields that MATLAB can access
   * The https://github.com/lcm-proj/lcm/blob/master/lcm-java/lcm/lcm/MessageAggregator.java[MessageAggregator] class provided a way to receive messages on a background thread and queue them for MATLAB.
   
  -Thus, even though the snippet looks similar to MATLAB code, all variables are actually Java objects. For example, the struct-like command message type is a Java object that exposes public fields as shown in the snippet below. Users can access them the same way as fields of a standard MATLAB struct (or class properties) resulting in nice syntax. The types are automatically converted according to the https://mathworks.com/help/matlab/matlab_external/passing-data-to-java-methods.html[type mapping].
  +Thus, even though the snippet looks similar to MATLAB code, all variables are actually Java objects. For example, the struct-like command type is a Java object that exposes public fields as shown in the snippet below. Users can access them the same way as fields of a standard MATLAB struct (or class properties) resulting in nice syntax. The types are automatically converted according to the https://mathworks.com/help/matlab/matlab_external/passing-data-to-java-methods.html[type mapping].
   
   [source,java]
   ----
  
positive.code: }
  ----
  
  Note that the _getNextMessage_ method expects a user settable timeout argument. In general it is important for blocking Java methods to have a timeout in order to prevent the main thread from getting permanently stuck inside Java. Otherwise this could cause the UI to become unresponsive and users may be forced to close MATLAB without being able to save their workspace. Being in a Java call also prohibits users from aborting the execution (ctrl-c), so timeouts should be reasonably short, i.e., in the low seconds.
  
  Passing in a timeout of zero serves as a non-blocking interface that immediately returns empty if no messages are available. This is often useful for working with multiple aggregators or for integrating asynchronous messages with unknown timing, such as user input.
  
  Overall, we thought that this was a well thought out API and a great example for a minimum viable interface that works well in practice. By receiving messages on a background thread and by moving the encoding and decoding steps to the Java language, the main thread was able to spend most of its time on actually working with the data.
  
  Some minor points for improvement that we found were:
  
  * The decoding step _fbk = types.feedback(msg.data)_ forced two unnecessary translations due to _msg.data_ being a _byte[]_, which automatically gets converted to and from _int8_. This could result in a noticeable performance hit when receiving larger messages (e.g. images) and could be avoided by adding an overload that accepts a non-primitive type that does not get translated, e.g., _fbk = types.feedback(msg)_.
  * The Java classes didn't implement https://mathworks.com/help/matlab/matlab_external/save-and-load-java-objects-to-mat-files.html[Serializable], which could become bothersome when trying to save the workspace. 
  * We'd prefer to select the decoding type during the subscription step, e.g., _lc.subscribe('FEEDBACK_CHANNEL', aggregator, 'types.feedback')_, rather than requiring users to instantiate the type manually. This would clean up the parsing code a bit and allow for a less confusing error message if types are missing.
  
  === Robot Operating System (ROS)
  
  http://www.ros.org[ROS] is by far the most widespread messaging framework in the robotics research community and has been officially supported by Mathworks' https://www.mathworks.com/products/robotics.html[Robotics System Toolbox] since 2014. The MATLAB implementation is built on RosJava, and Simulink code generation is built on ROS C++.
  
  The API was designed such that each topic requires dedicated publishers and subscribers, which is contrary to LCM where each subscriber is able to listen to multiple channels (topics). This in combination with specifying the type on initialization removes much of the boiler plate code necessary for dealing with message types. 
  
  [source,matlab]
  ----
  
negative.code: 
  == Final Notes
  
  Contrary to the situation a few years ago, nowadays there exist interfaces for most of the common message passing frameworks that allow researchers to do at least basic hardware-in-the-loop prototyping directly from MATLAB. If for some reason you need to write a custom interface, we would recommend to start with an LCM-like implementation and to add complexity as needed.
  
  If you don't already have a clear preference between C++ and Java, we would recommend to start with a Java implementation. MEX interfaces require a lot of conversion code that MATLAB would automatically handle for Java calls.
  
  While interfaces that only expose MATLAB code can provide a much better and more consistent user experience (e.g. help documentation), there is a significant cost associated with maintaing all of the involved layers.
  
  Finally, even though message passing systems are very widespread in the robotics community, they do have drawbacks and aren't appropriate for every application. Future posts in this series will focus on some of the alternatives.
  
  