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: end
  ----
  
  They designed the API such that each topic required dedicated publishers and subscribers, which was contrary to LCM where each subscriber was able to listen to multiple channels (topics). This in combination with specifying the type on initialization removed most of the boiler plate code necessary for dealing with message types. The resulting user code was more concise and was arguably more readable than LCM's interface.
  
  [source,matlab]
  ----
  % Setup Publisher
  chatpub = rospublisher('/chatter', 'std_msgs/String');
  
  % Fill message
  msg = rosmessage(chatpub);
  msg.Data = 'Some test string';
  
  % Publish
  chatpub.send(msg);
  ----
  
  They offered three different APIs for receiving messages: blocking calls, non-blocking calls, and callbacks. This allowed users to choose the style they were most comfortable with.
  
  [source,matlab]
  ----
  % Setup Subscriber
  laser = rossubscriber('/scan');
  
  % (1) Blocking receive
  scan = laser.receive(1); % timeout [s]
  
  % (2) Non-blocking latest message (may not be new)
  scan = laser.LatestMessage;
  
  % (3) Callback
  callback = @(msg) disp(msg);
  subscriber = rossubscriber('/scan', @callback);  
  ----
  
  Overall, we found that the ROS support toolbox looked very nice and was a great example of how seamless external languages could be integrated with MATLAB. We also really liked that they offered a way to load log files (rosbags).
  
  One concern we had was that there didn't seem to be a simple non-blocking way to check for new messages, e.g., a _hasNewMessage()_ method or functionality equivalent to LCM's _getNextMessage(0)_. We often found this useful for applications that combined data from multiple topics that arrived at different rates (e.g. sensor feedback and joystick input events). We checked whether this behavior could be emulated by specifying a very small timeout (see below), but any value below 0.1s seemed to never successfully return.
  
  [source,matlab]
  ----
  
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
  
  