TODO

Project TODO list:
(IMO: 2012/6/30/2012) 1. matlab/tests/cpp_sim_verify.m
        This function is meant to load solutions given by cpp/run_sim.cpp (in the 
    form of json result files) and run the control inputs through the matlab 
    simulator for the chain configuration specified.  Theoretically, each 
    intermediate state specified in the solution by OMPL should be hit by 
    running the OMPL specified controls through the matlab sim.
        This is a nice way of identifying the existence of a problem, although
    it doesn't give us too much of an idea of where the problem is because
    the entire system is involved.

(IMO: 2012/07/11) 2. Dynamics Verification (Energy)
        For both the matlab sim and the c++ sim, we need to verify
    that for an undamped system with no torque inputs, the energy
    is constant.
        With this we should see blatant errors in the simulator (manifesting,
    hopefully, as huge energy discrepencies) and integrator problems.

3. Look into the integrator the C++ sim is using with boost
        I already know there's one error in the integrator (We should
    figure out who to report this to?), so we might need to do something
    about this if it proves to be a problem.
        There's a good chance that it isn't a problemf for us, because
    the duration that OMPL asks the integrator to simulate for might
    be shorter than one timestep. (Now that I think about it,
    we should make sure that in the case that duration < timestep
    the integrator doesn't still simulate for timestep)

4. (IMO [ditched effor]: ?) Planning Graph Visualization
        We need a nice way to visualize planning trees in the high
    dimensional space we're dealing with.  I've started a branch 
    "python_vis_tree" with python code that loads json result 
    files and makes the planning tree available in an easy format.

5. Hardware 1
        Assembly of the 3 modules we have. Also, we need to get
    4 same model XBees running and figure out how they work
    in the one to many mode.

6. Hardware 2
        We need to figure out how to modify/redesign the current modules
    so that wire routing is clean and contained within the module.  It 
    would also be nice to remove any excess material, since we're torque
    limited.

7. Hardware 3
        We need to figure out the specific physical properties of any
    modules we want to run physical tests with.  This includes,
    in the parlance of the simulator, r_im1 and r_ip1, m, and the
    inertia matrix I.

8. Simulation/Planning result visualizer
        For both Matlab and C++ dynamics sims, it would be nice
    to have a "pretty" visualizer for playing back planning solutions
    (both their kinematics, and running torques through the dynamics sims
    to make sure that the result is the same as what OMPL thinks it should
    be)

9. Test Stand
        For our initial tests (with 3 modules) we need a test stand onto which
    we can mount the modules.

10. Add 6 DOF joint to "base" of module chain in dynamics sims
        The final "goal" is to have a chain of modules jump off of
    a table into a tube (Parkour jump off of ledge and dive/tuck into
    drainage pipe, or something?).  With the dynamics sim as it is now,
    the base module must rotate around a fixed axis, which doesn't
    allow a chain to "jump".  The sim supports arbitrary 6 DOF joints
    between rigid bodies, so the capability is there.  It just needs 
    to be put in.

11. Add "take off" collision support.
        To avoid having to build full collision support into the dynamics
    sim, we can just assume the base module (with a 6 DOF joint connecting
    it to the ground) does not slide and cannot penetrate the table.  However,
    when the normal force with the table reaches 0 we can allow the module
    to leave the table. This allows us to "jump".

12. Motor characteristics and model
        We're probably going to need a motor model in the dynamics sim to
    get good results.  This needs to be added in whatever degree of 
    fidelity proven necessary.  We also need to get the full characterization
    of the motors we're using (Matt probably has this for us).

13.(UJB: 2012/07/16) Brain Board + Motor Controller
        We need to figure out how to use the Brain board and Motor controller.

14. (UJB: 2012/07/16) Write code for sending the torque to the modules.
        With planning results from OMPL, we need to "play" the 
    torques onto the module chain.  Since the results are
    outputted to results.txt in json format, we can do
    this in whatever language we want (python!).

(IMO: 2012/06/23) 15. Re-factor the solution outputting to use jsoncpp's output mechanism
        Right now the json output is completely manual, and as a result
    there are random result_file << "}" << std::endl and such sprinkled
    everywhere.  This means that moving anything around almost definitely
    breaks the json output.  Using jsoncpp's mechanism for this
    will solve this problem.