anchor.diff:  
   == Final Notes
   
  -Contrary to the situation a few years ago, nowadays there already are 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.
  +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 are not appropriate for every application. Future posts in this series will focus on some of the alternatives.
  -
  +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.
  +
  
positive.code: subscriber = rossubscriber('/scan', @callback);  
  ----
  
  Contrary to LCM, all objects that are visible to users are actually MATLAB classes. Even though the implementation is using Java underneath, all exposed functionality is wrapped in MATLAB classes that hide all Java calls. For example, each message type generates a custom wrapper class. The code below shows a simplified example for a message that has a _Name_ property.
  
  [source,matlab]
  ----
  
negative.code: 
  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.
  
  A second hurdle is that while MATLAB is very efficient in the execution of math operations, it is not particularly well suited for byte manipulation. This makes it difficult to develop code that can efficiently create and parse binary message formats that the target hardware can understand. Thus, after having the main thread spend its time waiting for and parsing the incoming data, there may not be any time left for performing interesting math operations.
  
  [.text-center]
  .Communications overhead in the main MATLAB thread
  image::matlab/comms-single-threaded.png[link="{imagesdir}/matlab/comms-single-threaded.png", width="100%"]
  
  Pure MATLAB implementations can work for simple applications, such as interfacing with an Arduino to gather temperature data or blink an LED, but it isn't feasible control complex robotic systems at high rates. Fortunately, MATLAB does have the ability to interface with other programming languages that allow users to create background threads that can offload the communications aspect from the main thread. This frees MATLAB to focus on the calculations that it has been optimized for.
  
  [.text-center]
  .Communications overhead offloaded to other threads
  image::matlab/comms-multi-threaded.png[link="{imagesdir}/matlab/comms-multi-threaded.png", width="100%"]
  
  Out of the box MATLAB provides two interfaces to other languages:  https://www.mathworks.com/help/matlab/matlab_external/introducing-mex-files.html[MEX] for calling C++ code, and the https://www.mathworks.com/help/matlab/matlab_external/product-overview.html[Java Interface] for calling Java code. There are some differences between the two, but at the end of the day the choice effectively comes down to personal preference. Both provide enough capabilities for developing sophisticated interfaces and have orders of magnitude better performance than required.  There are additional interfaces to https://www.mathworks.com/help/matlab/calling-external-functions.html[other languages], but those require additional setup steps.
  
  == Message Passing Frameworks
  
  https://en.wikipedia.org/wiki/Message_passing[Message passing] frameworks such as http://www.ros.org/[ROS] and https://lcm-proj.github.io/[LCM] have been widely adopted in the robotics research community. At the core they typically consist of two parts: a way to exchange data between processes (e.g. UDP or TCP) as well as a defined messaging format for encoding and decoding the data. They allow systems to be built with distributed components (e.g. processes) that run on different computers, different operating systems, and different programming languages.
  
  The resulting systems are very extensible and provide convenient ways for prototyping. For example, a component communicating with a physical robot can be exchanged with a simulator without affecting the rest of the system. Similarly, a new walking controller could be implemented in MATLAB and communicate with external processes (e.g. robot comms) through the exchange of messages.
  
  The flexibility, wide-spread adoption, and support for different languages make them a nice starting point for a MATLAB-hardware interface.
  
  ////
  In https://en.wikipedia.org/wiki/Message_passing[Message passing] systems components communicate by exchanging messages rather than by calling functions directly. At the core they consist of two parts, a way to exchange messages (e.g. UDP or TCP), and a consistent messaging format. They allow system to be built with components (e.g. processes) that run on different computers, different operating systems, and different programming languages. 
  