anchor.diff:  end
   ----
   
  -We thought that this was a nice interface for Arduino users that also served as a great example for the performance problems caused by the synchonous programming model. On our test machine we were only able to get about 80 operations (reads or writes) per second, so the above loop would run at maximum 40 Hz. This would be enough for simple Arduino-type problems, but far too slow for serious robotics applications.
  +We thought that this was a nice interface for Arduino users that is significantly more usable than the previously common approaches of exchanging strings over serial.
  +
  +Unfortunately this interface also serves as a great example for the performance problems caused by the synchronous programming model. On our test machine we were only able to get about 80 operations (reads and writes combined) per second, so the above loop would run at maximum 40 Hz. This would be enough for simple Arduino-type problems, but far too slow for serious robotics applications.
   
   Note that most of the overhead comes from waiting for device responses, so code generated from Simulink models that gets deployed locally on the device should be able to run significantly faster.
   
  
positive.code: === 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.
  
  [source,matlab]
  ----
  
negative.code: end
  ----
  
  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 (such as in the snippet below), but any value below 0.1s seemed to never successfully return.
  
  [source,matlab]
  ----
  