anchor.diff:  end
   ----
   
  -A minor issue we found when looking through the code was that the decoding step _fbk = types.feedback(msg.data)_ forces two unnecessary translations due to _msg.data_ being a _byte[]_, which automatically gets converted to and from _int8_. This could result in a noticeable performance hit when receiving larger messages (e.g. images) and could be avoided by adding an overload that accepts a a non-primitive type that does not get translated, e.g., _fbk = types.feedback(msg)_. The Java classes also don't implement _Serializable_, which could become a problem when trying to save the workspace. 
  +A minor issue we found when looking through the code was that the decoding step _fbk = types.feedback(msg.data)_ forces two unnecessary translations due to _msg.data_ being a _byte[]_, which automatically gets converted to and from _int8_. This could result in a noticeable performance hit when receiving larger messages (e.g. images) and could be avoided by adding an overload that accepts a non-primitive type that does not get translated, e.g., _fbk = types.feedback(msg)_. The Java classes also don't implement _Serializable_, which could become a problem when trying to save the workspace. 
   
   Overall, we think that this is well thought out API and a great example of a minimum viable interface that works well in practice.
   
  
positive.code: 
  MATLAB(C) is a programming language and environment designed for scientific computing. It is one of the best languages for developing robot control algorithms and is extremely widespread in the research community. It is generally thought of as an offline programming language, but it is technically possible to add hardware into the loop. This post discusses the most common approaches and compares existing projects.
  
  Prototyping directly on real hardware can significantly speed up development because it reduces the time between considering an idea and getting feedback on whether the algorithm can withstand real world physics. A workflow that requires researchers to port prototype code to another language before being able to test on real hardware can lead to multiple weeks or months being lost on chasing down rabbit holes. Additionally, many controls engineers do not have a computer science background, so requiring knowledge of C++ can pose a significant barrier.
  
  We noticed that over the past few years several groups seem to have identified this as a problem and started to develop ways to control hardware directly from MATLAB. Since there aren't any guidelines for developing such interfaces, we looked at several different projects and compared the approaches they took.
  
  Note that this blog post is purely focused on the MATLAB scripting language and does not discus Simulink or code generation.
  
  == Technical Background
  
  
negative.code: 
  This poses a problem for real-time control because all communications to hardware 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.
  
  A second hurdle is that while MATLAB is extremely efficient in the execution of math operations, it is not particularly well suited for byte manipulation. This makes it very difficult to develop code that can efficiently create and parse binary message formats that the target hardware can understand.
  
  After having the main thread spend its time on waiting for and parsing the incoming data, there may not be any time left for performing interesting math operations. Pure MATLAB implementations do work for simple applications, e.g., interfacing with an Arduino to gather temperature data or blink an LED, but it is not feasible control complex robotic systems at reasonable rates.
  
  Fortunately, MATLAB does have the ability to interface with other programming languages that allow users to create background threads in order to offload the communications aspect from the main thread. Out of the box MATLAB provides two interfaces to other languages:  https://www.mathworks.com/help/matlab/matlab_external/introducing-mex-files.html[MEX] for calling C++ code and the https://www.mathworks.com/help/matlab/matlab_external/product-overview.html[Java Interface] for calling Java code. There are https://www.mathworks.com/help/matlab/calling-external-functions.html[other interfaces] as well, but those require additional setup steps.  
  
  There are some subtle differences between the capabilities of the MEX and Java interfaces, but at the end of the day the choice mostly comes down to personal preference. Both languages provide enough capabilities for developing sophisticated interfaces, and have orders of magnitude better performance than required.
  
  