anchor.diff:  :imagesdir: ../images
   //:imagesdir: https://github.com/ennerf/ennerf.github.io/raw/master/images/
   :source-highlighter: none
  +
  +////
  +What do we want to tell?
  +(?) Distributed systems have quite a bit of overhead and complexity. Performance wise they often matter less than expected. There is more overhead in sharing the work than in doing the work. Lots of stuff is sequential in nature anyways.
  +(*) Distributed systems work well for long running projects that have a variety of people working on it in potentially different languages. It's also nice for simulation.
  +(*) Distributed systems get in the way if it's a single person hacking on a new problem. Libraries are much faster to develop with.
  +(*) MATLAB is fast enough. Common calls can be packaged into super-fast Java libraries.
  +(*) All of the comms and calculations etc. can be done within the MATLAB process.
  +(*) Logging is important. MATLAB plotting is great for debugging.
  +(*) Dynamic languages like MATLAB or Python are better for hacking things together
  +(*) C++ is not a prerequisite for good performance. The language choice doesn't matter as much as people think it does.
  +(*) Modular systems require a fundamentally different approach to System development.
  +(*) Two weeks development means 4 days programming and assembling the robot, and the rest of the time tuning gains to make it stable.
  +(*) Having reliable hardware that allows working without simulation helps.
  +
  +
  +Possible Storylines:
  +(*) How we built a complex robot (Igor) in 2 weeks: Don't bash distributed systems, focus on figuring out low level primitives (forward, left, right, etc.) as quickly as possible so it can be integrated with targets etc. later.
  +-- Should discuss hardware/simulation etc. as well?
  +-- How do math libraries like FK/Trajectories fit in?
  +(*) Last post discussed distributed systems. What are the alternatives?
  +-- Should probably include a list of other projects
  +(*) Saying we built this robot in 2 weeks and it's entirely controlled by a single MATLAB instance sounds like snake-oil salesmanship. Below is the background story.
  +-- 
  +(*) The internal structure of the HEBI MATLAB API. Software for rapid prototyping.
  +
  +
  +
  +////
  +
   
   ++++
   <link rel="stylesheet" href="https://cdn.rawgit.com/ennerf/ennerf.github.io/master/resources/highlight.js/9.9.0/styles/matlab.css">
  
positive.code: 
  IROS 2017: Saying we built IGOR II in 2 weeks and it runs entirely from MATLAB sounds like snake oil salesman. Thus, post detailing how it's possible.
  
  == Typical System
  
  * Message passing
  * multiple processes for various stuff (trajectories / robot comms / kinematics / IK / Jacobians / etc.)
  * MATLAB hooked in via message passing
  
  === Issues
  
  * Slow to develop
  * Significant cognitive overhead
  * Hard to follow exact control flow
  * Hard to make sure timings are correct
  * Most CPU is used for messaging, not doing actual work
  
  == Rethinking the system
  
  
negative.code: == Math Libraries
  
  * Most core functionality is essentially free when implemented in Java. Can run in same thread without any issue.
  ** FK 6 dof arm in 240ns. Numerical Jacobian in 4us. Calling a single Java function w/ return arguments 10-20 us.
  * Java is completely sufficient.
  
  == Putting it all together
  