anchor.diff:  
   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 we were to run a loop at 100Hz and it took a message ~8ms for a round-trip, the main thread would spend 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 on waiting for and parsing the incoming data, there may not be any time left for performing interesting math operations.
  +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 is not 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 in order to offload the communications aspect from the main thread. This frees MATLAB to focus on the calculations that it has been optimized for.
  +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 mostly 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.
  +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 adopated 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), and 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.
  -
  -The same principle works for other components as well, e.g., a new walking controller could be implemented in MATLAB and communicate with external processes (e.g. robot comms) through the exchange of messages.
  -
  -Their flexibility, wide-spread adoption, and support for different languages make them a nice starting point for a MATLAB-hardware interface.
  +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. 
  
positive.code: 
  === Lightweight Communication and Marshalling (LCM)
  
  https://lcm-proj.github.io/tut_matlab.html[LCM] is a message passing framework that was developed at http://www.mit.edu/[MIT] in 2006 for their entry to DARPA's Urban Challenge. In the robotics community it became a popular alternative to ROS and was as far as we know the first messaging framework that supported MATLAB as a core language. We found its implementation to be comparatively simple and would recommend it as a starting point when developing similar interfaces.
  
  The snippet below shows how the MATLAB code for sending a command message could look like. The code creates a struct-like _message_, sets desired values, and publishes it on the appropriate channel.
  
  
negative.code: }
  ----
  
  Note that the _getNextMessage_ method expects a user settable timeout argument. In general it's 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. Its minimalistic implementation is comparatively simple and we would recommend it as a starting point for developing similar interfaces.
  
  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 doesn't 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. While the Simulink code generation uses ROS C++, the MATLAB implementation is built on the less common RosJava.
  
  The API was designed such that each topic requires dedicated publishers and subscribers, which is different from 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]
  ----
  