anchor.diff:  === Data Distribution Service (DDS)
   
   In 2014 Mathworks also added a https://www.mathworks.com/hardware-support/rti-dds.html[support package for DDS], which is the messaging middleware that ROS 2.0 will be based on. It supports MATLAB and Simulink, as 
  -well as code generation. 
  -
  -Unfortunately, we didn't have all the requirements to get it setup, and we couldn't find much information about the underlying implementation. Based on looking at some of their intro videos, the resulting code looked as follows.
  +well as code generation. Unfortunately, we didn't have all the requirements to get it setup, and we couldn't find much information about the underlying implementation. Based on looking at some of their intro videos, the resulting code looked as follows.
   
   [source,matlab]
   ----
  
positive.code: === Robot Operating System (ROS)
  
  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. Simulink code generation was implemented on top of ROS C++ and the MATLAB interface was built on top of RosJava.
  
  We unfortunately haven't had a chance to use the library in a real project, so our impressions were purely based on looking through the toolbox files and the compiled Java bytecode. As far as we could tell they built a small Java library that wrapped RosJava functionality and provided an interface that was easier to call from MATLAB. Most of the actual logic seemed to be implemented in MATLAB code, but they made extensive use of 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.
  
  
negative.code: hx_close();
  ----
  
  
  At the top level, the API consisted of https://bitbucket.org/osrf/haptix-comm/src/a961986b0254a3dbcabcc89ba14f78915d5d968a/matlab/[several MATLAB functions] that provided help text and forwarded calls to an underlying MEX function.
  
  [source,matlab]
  ----
  % Example for a forwarding function
  % <help text>
  function result = hxs_add_model(sdf, name, pos, orient, gravity_mode)
      result = hxgz('add_model', sdf, name, pos, orient, gravity_mode);
  end
  ----
  
  The MEX code was implemented in a similar way as the ZeroMQ-matlab project in that there was a single function implementation (https://bitbucket.org/osrf/haptix-comm/src/a961986b0254a3dbcabcc89ba14f78915d5d968a/matlab/hxgz.c[hxgz.c]) that expected a string as the first argument in order to select the desired action. The MEX function internally translated the additional input arguments according to the action, and called a corresponding function in their C API. The underlying C code then sent an appropriate message via ZeroMQ. The snippet below shows a simplified example for an action implementation.
  
  [source,c++]
  ----
  // Dispatch to the appropriate function based on the first argument
  // ...
  else if (!strcmp(funcName, "add_model"))
      hxgzs_add_model(nlhs, plhs, nrhs-1, prhs+1);
  
  // ...   
  void hxgzs_add_model(int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[]) {
      // ... input translation
      
      // Call to C API
      if (hxs_add_model(sdf, name, x, y, z,
                        roll, pitch, yaw, gravity_mode, &model) != hxOK)
          mexErrMsgIdAndTxt("HAPTIX:hxs_add_model", hx_last_result());
  
    // ... output translation
    plhs[0] = model_to_matlab(&model);
  }
  
  ----
  
  Note that their http://gazebosim.org/haptix[documentation] mentioned that the MATLAB API was generated from their C API. Without auto-generation it would be extremely tedious to maintain and extend four or more calling layers for every function.
  
  Overall we found that their implementation was done quite well and we assume that they must have spent significant time on creating this interface. It was also nice to see that they included functionality to enable and disable logging.
  
  While we really liked their implementation, we thought that some minor changes could simplify the resulting API:
  
  * More than half of the example code could've been replaced by adding a helper function that returns a default command struct (or making it a class so that users can't mess with the fields), e.g., _hxs_command_struct()_.
  * The disabled state could've been represented by NaN or empty values rather than introducing separate fields for boolean flags.
  * https://bitbucket.org/osrf/haptix-comm/src/a961986b0254a3dbcabcc89ba14f78915d5d968a/matlab/hx_update.m[_hx_update()_] could've benefitted from a second return argument that indicates whether the returned state is new, and a blocking call with timeout to get rid of the busy loop.
  
  == Standalone Systems
  
  