anchor.diff:  end
   ----
   
  -Overall, we found that the ROS support toolbox looks very nice and is 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).
  -
   === 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 is based on. It supports MATLAB, Simulink, as 
  
positive.code: :hp-tags: MATLAB, Java
  :imagesdir: ../images
  
  MATLAB(C) is a programming language and environment designed for scientific computing. It is one of the best languages for developing control algorithms and is extremely widespread in the robotics research community. Typically researchers use it to prototype algorithms and ideas that subsequently get implemened in another language like C/C++ in order to be tested on real hardware. 
  
  Unfortunately, this porting step causes substantial delays in the feedback loop between considering ideas and testing them in practice. For example, it may take weeks to realize that a given approach may not be able to deal with real world sensor noise. Additionally, many controls engineers do not have a computer science background, and requiring knowledge of C/C++ can pose a significant barrier.
  
  Having experienced this workflow ourselves for many years, we believe that many labs could significantly speed up their research efforts if the hardware could be controlled directly from MATLAB.
  
  We noticed that over the past few years several groups seem to have identified this as a problem and started to develop hardware interfaces for MATLAB. This post will look at some of the available projects and discuss the approaches that were taken to solve this problem.
  
  Note that this blog post is focused purely on the MATLAB programming language and does not discuss Simulink. http://www.mathworks.com[Mathworks] has spent significant efforts on developing automated code generation from Simulink models that may get rid of  tedious manual translation steps.
  
  == Background
  
  The main limitation when trying to use MATLAB to interface with hardware is that the language is fundamentally single threaded. It has been designed to allow non-programmers to do complex math operations without needing to worry about computer science concepts like multi-threading and synchronization.
  
  This poses a problem because all communications are forced to happen synchronously in the main thread. For example, if we wanted 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 the response and doing no actual work.
  
  The second hurdle is that while MATLAB can execute math operations extremely efficiently, it can be slow and tedious to create and parse the binary message formats that the target hardware can understand.
  
  Thus, a lot of time gets spent on the communications side, resulting in almost no time budget for performing the interesting math operations. Pure MATLAB implementations still work for simple applications, e.g., interfacing with an Arduino to blink an LED at ~50Hz, but it is not feasible to control complex robotic systems at reasonable rates.
  
  Fortunately, MATLAB does have the ability to interface with other programming languages such as Java and C++ that allow users to create background threads in order to offload the communications aspect from the main thread.
  
  ////
  == Message Passing Frameworks
  
negative.code: 
  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. The MATLAB interface is implemented on top of RosJava. The Simulink code generation aspect leverages ROS C++.
  
  So far we didn't have a chance to use the library in a project, so our impressions are purely based on a quick look at the toolbox files and the compiled Java bytecode. As far as we could tell they built a small Java library that wraps RosJava functionality and provides an interface that is easier to call from MATLAB. Most of the actual logic seems to be implemented in MATLAB code, but they make extensive use of various Java libraries for problems that would be difficult to implement in pure MATLAB, e.g., listing networking interfaces or doing in-memory decompression of images.
  
  The underlying Java interface is completely hidden from users as all of the Java calls happen inside of wrapping MATLAB classes. For example, there is a wrapper class for each Java message type that exposes typical MATLAB properties (get/set) that modify the state of the underlying Java object. Similarly, all Java exceptions get intercepted and wrapped in a MATLAB exception before being exposed to the user. The code below shows a simplified example of a message wrapper.
  
  [source,matlab]
  ----
  