anchor.diff:  
   This custom API worked very well for our lab until we started building a much more sophisticated generation of hardware that had many tuning options that users needed to access. Due to the nature of message passing systems, each new sensor or settable option required changes to every level of the stack, including the firmware, the network protocol, the receiving process, the message type, as well as the API layer. It quickly became a maintenance nightmare to go through this many layers and we started writing more sophisticated APIs that communicated with the hardware directly, which eliminated several layers.
   
  -
  -// LCM improvements
  -Note that the call to _msg.data_ likely converts Java's _byte[]_ into an _int8_ vector that gets converted back into a _byte[]_ when calling the Java method. This results in the language barrier being crossed twice unnecessarily, which may be quite expensive for larger messages.
  
positive.code: end
  ----
  
  Overall, the ROS support looks quite nice and even includes support for importing rosbags and doing path planning. They pre-bundled a lot of commonly used message types, but also support the use of custom messages. This toolbox proably represents the golden standard of how well a library in another language can be seamlessly integrated with MATLAB.
  
  == Related Work
  
  We noticed that over the past few years several groups seem to have come across the same problem and started developing bindings for MATLAB. When we started 
  
  over the past few years there has been quite a bit of development in this area. When we started to look into interfaces, there were almost no resources available. 
  
  We noticed that there has been quite a bit of development in this area. There were almost no available resources when we started with our first attempts several years ago, but recently it seems that several groups have identified the same problem and started to develop bindings for MATLAB.
  
  
  == Related Work
  
  When we started working on APIs for MATLAB in ~2011 LCM was the only interface we were aware of. However, it seems that in the past years such APIs have become more popular. Now there are several projects with MATLAB bindings, which can generally be grouped into two categories. Below is a list of the existing APIs that we are aware of.
  
  // Split into fixed robots and modular systems? Maye split Generic Message passing systems, fixed systems (Nao etc.), reconfigurable modular systems
  
  * https://www.mathworks.com/hardware-support/rti-dds.html[DDS]
  
  * Interfaces to message passing frameworks. Usually includes background threading. (Async) Requires external applications to communicate with robot.
  
  ** http://gazebosim.org/tutorials?cat=haptix&tut=haptix_matlab[OSRF Haptix], MEX/C interface to http://ignitionrobotics.org/[ignition-transport] (MEX)
  
  ** https://lcm-proj.github.io/tut_matlab.html[LCM] (Java)
  
  ** https://www.mathworks.com/hardware-support/robot-operating-system.html[ROS Support from Robotics System Toolbox] (Java)
  
  ** https://github.com/smcgill3/zeromq-matlab[ZeroMQ] (MEX)
  
  ** https://github.com/ragavsathish/RabbitMQ-Matlab-Client[RabbitMQ] (Java)
  
  
  
  * Interfaces to the raw communication protocol. Usually relies on main thread for the communication aspect. (Sync)
  
  ** http://www.robodk.com/Matlab-API.html[RoboDK] (sort of) very high level commands to their main application
  
  ** http://support.robotis.com/en/software/dynamixel_sdk/usb2dynamixel/windows/matlab.htm[Dynamixel API]. Extremely low level down to endian conversions
  
  ** https://www.mathworks.com/hardware-support/arduino-matlab.html[Arduino] Support from MATLAB
  
  ** https://www.mathworks.com/hardware-support/android-sensor.html[TMW Android Sensor support] not real-time? only logging?
  
  ** https://henschel-robotics.ch/hdrive/software/[Henschel Servos] writes xml messages using MATLAB's tcp libraries to a web server embedded on the device
  
  
  
  * Other
  
  ** http://fileadmin.cs.lth.se/cs/education/MMKN30/Nao/download/Documentation/dev/matlab/index.html[Nao]
  
  ** https://sourceforge.net/projects/urbi/?source=typ_redirect[URBI] http://agents.csse.uwa.edu.au/aibosig/resources/downloads/tutorial_liburbiMatlab_0.1.pdf[tutorial] not maintained anymore? (2004 last update?)
  
  
  Table with features? Name, Async, Language, Performance (?), Protocol (binary/text), Object Oriented?, Comment
  
  
  // Example1:
  
  Message passing systems don't work very well for prototyping with modular systems. For example, consider a case of kinesthetic control where the feedback of a master robot is used to control a second slave robot. This would require changes to the messages, which always results in significant overhead. Definition need to be changed, messages need to be generated, the receiving process needs to be modified, everything has to be recompiled for the target platform and so on. This overhead is justifiable for static systems that live for a long time, but it is a dealbreaker for modular systems that were constructed and programmed in an hour for a quick YouTube video.
  
  ////
  When showing syntax for other APIs that show setting of a position command, we can show the MSI demo of 1 limp robot controlling position/velocity on another. Maybe include logging as well.
  
  Performance is actually better than original C++ due to no message passing overhead.
  
negative.code: end
  ----
  
  They designed the API such that each topic requires dedicated publishers and subscribers, which is contrary to LCM where each subscriber can listen to multiple channels (topics). This in combination with specifying the type on initialization removes most of the boiler plate code necessary for dealing with message types. The resulting user code is more concise and is arguably more readable.
  
  [source,matlab]
  ----
  