diff --git a/README.md b/README.md
index 8fb189b80648c4893a3b8d57c078cff983c98f97..c6148e4b98ff7aac21f7641bbd28c0fe1085b03d 100644
--- a/README.md
+++ b/README.md
@@ -6,24 +6,26 @@
 
 # general info
 -------------
-- all of the code has been used and tested on Ubuntu 22 LTS
-- both Python and C++ implementations are available, there's examples of both (both for the libraries
-  used and for their combination)
-- all of the code is initially written in C++ - ur_rtde uses pybind to generate Python bindings, and
-  so does pinocchio for the most part. thus almost all the functions used are identical across languages, 
-  and so c++ implementations can be looked at to analyse python functionality as well
+- code is developed on Arch Linux, also tested on Ubuntu 22, should work on any Linux
+- code is written in Python, will be re-written in C++ with Python bindings in the future
+- all of the library code is written in C++ with Python bindings 
+  - ur_rtde 
+  - pinocchio 
+  - crocoddyl in the future
 - matrix operations are done with Eigen in C++, and NumPy in Python
 
 # libraries used and their purpose
--------------
-- ur_rtde for the client-side real-time interface for ur robots (we have a UR5e)
-- pinocchio for dynamics intergration, and other robotics-related math on the client side
+-----------------------------------
+- ur_rtde for the client-side real-time interface for ur robots (we have a UR5e), will expand for other robots in the future
+- pinocchio for robot dynamics calculations
 - meshcat for visualization (has nice integration with pinocchio)
+- crocoddyl for optimal control
 - Dockerized ur simulator as a simulator (it's a bad simulator, but it uses the same robot-communication API 
   as the real robot, making coding and testing easier)
+- Docker is used for shipping 
 
 # contents of this repository
--------------
+---------------------------------
 - basic documentation can be found in the docs directory: official UR documentation on the robot's capabilities
   and its interface, short instructions on installing Ubuntu, ur_rtde, pinocchio, gepetto and the simulator
 - basic closed-loop inverse kinematics control is implemented in both C++ and python. the C++ version
@@ -35,7 +37,7 @@
 - some basic tests will be here as well, while full projects built on this repo will be in separate repos
 
 # installation and operating instructions
--------------
+------------------------------------------
 For all of the listed items, consult their specific documentation in the docs folder, and do your own googling.
 Note that for most items you can install through the ubuntu package manager apt, or through the python
 package manager pip. Likewise, you can compile the libraries and install from local files. Both options
@@ -49,69 +51,39 @@ and their examples. Looking around and running these examples is the best way to
 and b) get to know the libraries. Of course also follow this up with reading on their documentation.
 
 Here is a checklist of what to do together with the key remarks.
-- install ubuntu on metal, i.e. do a real install on your machine. if you want to play around with virtual machines,
-  or compile all the libraries on windows or something else, this is OK, but proceed at your own risk and with less support
+- install ubuntu either on metal, i.e. do a real install on your machine, or build the provided docker image (on windows use wsl),
+  or compile all the libraries on windows or something else, but in that case proceed at your own risk and with no support
+if installing on metal:
 - install ur_rtde https://gitlab.com/sdurobotics/ur_rtde
-- create a fixed ip connection to verify that you can connect to the robot. create a new Ethernet connection,
-  and under IPv4 setting put 192.168.1.101 as the host (your) address, 255.255.255.0 under netmask
-  and 192.168.1.1 as gateway (just in case). the robot's ip is fixed to 192.168.1.102. connect to the network 
-  once you've created it. put the robot's IP into the examples given in ur_rtde and verify the connection (select
-  an example with the robot moving and see that it moves).
 - install pinocchio: https://gepettoweb.laas.fr/doc/stack-of-tasks/pinocchio/master/doxygen-html/index.html , 
   https://stack-of-tasks.github.io/pinocchio/download.html , https://github.com/stack-of-tasks/pinocchio .
-- compile and run click in this repo. note to run gepetto-gui if you want visualization
-- run clik.py
-- install docker and the simulator. change flags in the code to simulation, go to 
+
+## simulation
+--------------
+- use the --pinocchio-only argument to integrate the dynamics. if you want to add external disturbances,
+  put them into the kinematics/dynamics equations
+- alternatively build the docker image of the simulator (Dockerfile is in the ur_simulator directory). 
+  use the --simulation argument. go to 
   the local website to see the teacher pendant emulation and put 127.0.0.1 as the ip,
   and see whether the code works. the simulator accepts the same commands as the robot.
   the only TODO is to add the gripper to the simulator somehow, but you can also just
   skip using it when simulating.
 
-#TODO re-organization of the repo
--------------
-- RIGHT NOW: get rid of all ur-specific calls outside of the manager.
-  make all other functions depend only on pinocchio.
-  this is the only way you actually get transferability.
-  this includes the tucking of all rtde_control/rtde_receive calls 
-  behind RobotManager wrappers (because other robot don't have rtde_control lel).
-  i'm also pretty sure there is not a single instant in which i call robot_manager.getQ() without
-  calling pin.forwardKinematics immediatelly afterward. so think about doing that in robot_manager.getQ().
-- instead of gepetto visualization, just run your python thing because it's the easiest to modify,
-  you don't need to develop anything new and know how to use it already. 
-- long term: write all code in c++, make python bindings with pybind. have common documentation 
-  and examples
-- short term: the long term goal is too big of a time sink right now both lack of experience
-  and the necessity of prototyping in python first (it's miles faster and time is of the essence).
-  thus c++ and python code will live separately until all python code is rewritten with proper bindings.
-  up until that time the c++ and python stacks will lead separate existances, each in it's own folder
-  which might as well be a different repository. this is the cleanest thing to do as then
-  both folders can be organized into a cmake project and python package without unrelated
-  files to make clutter and cause confusion.
-- the pyproject.toml actually brakes local install so i'm just keeping it out for now. sweet jesus
-  what a mess
-- instead of using a debug argument and ifs for prints,
-  use built-in python logging
-
-#TODO: write instruction for extending the library to new robots
--------------
-- make sure the base frame of the robot aligns with base frame of the pinocchio model
-  you get from the urdf. even better if you make sure the urdf is correct (change it to
-  be correct), because then it will be transferable to simulators etc
-- todo the rest (will probably happen while i make this work on panda let's be real)
-
-#TODO for current students
--------------
-- explain hom transf mat
-- make this documentation prettier
-
-# TODO for profit
--------------
-- writing documentation, making text and video tutorials to the point where this can be used as teaching material
-- do the documentation with doxygen so that you get webpages from markdown as well
+## connecting to the real robot
+-------------------------------
+- create a fixed ip connection to verify that you can connect to the robot. create a new Ethernet connection,
+  and under IPv4 setting put 192.168.1.101 as the host (your) address, 255.255.255.0 under netmask
+  and 192.168.1.1 as gateway (just in case). the robot's ip is fixed to 192.168.1.102. connect to the network 
+  once you've created it. put the robot's IP into the examples given in ur_rtde and verify the connection (select
+  an example with the robot moving and see that it moves).
+- run clik.py to verify it works
 
-#TODO for fun and profict. general point: get a collection of control algorithms for the arm
+# some TODOs
 -------------
+- instead of using a debug argument and ifs for prints, use built-in python logging
 - implement and test other inverse kinematics algorithms
-- rewrite finalized dmp (and other) code into C++
-- learn pybind, create python bindings for that code
+- use pyproject.toml for python packaging. it actually brakes the current local install so it is avoided for now. 
+- write all code in c++, make python bindings with pybind. have common documentation 
+  and examples
+- do the documentation with doxygen so that you get webpages from markdown as well
 - create a DMP from multiple trajectories (actually learn a DMP from multiple examples)
diff --git a/TODOS_2024-03-23 b/TODOS_2024-03-23
deleted file mode 100644
index 35427756e463b810d1fe9dfed61e5f241ff28303..0000000000000000000000000000000000000000
--- a/TODOS_2024-03-23
+++ /dev/null
@@ -1,13 +0,0 @@
-in order of priority
---------------------
-1. real-time plotting (need to see what's happening as it's happening,
-   this is here primarily to aid in debugging) - DONE
----> have a list of what's possible to plot and then select what's selected - TODO make logging smoother and uniform accross code
-2. debug dmp end-of-trajectory shennanigans - DONE (at least mostly)
-3. implement compliantMoveL - DONE
-4. fix getMarkerOffset - DONE
-5. add waypoints to marker pick up
-6. fix anything that looks problematic in drawing
-7. switch to robot_manager.step() to ensure you're not double-computing things
-8. implement cartesian dmp 
-9. faster visualizing (process in a different thread)
diff --git a/TODOS_2024_09_19 b/TODOS_2024_09_19
index 855cc50363f47197c77745537d11b1d6e71feb42..655617a9d82f4eaf3c3d927fb272dab568bd83e3 100644
--- a/TODOS_2024_09_19
+++ b/TODOS_2024_09_19
@@ -4,12 +4,12 @@ and that means a docker image that just needs to be built.
 goal 1: ease of use
 -----------------------
 make a docker image installing everything
-1. get clik with visualization to work in a ubuntu22 docker
-2. write down the installation process in a Dockerfile
-3. make the container more user friendly:
-  --> use build-user.sh from markus' ros-containers repo to create a user
-  --> folder with some basic goodies like a .bashrc or .zshrc
-  --> some text editor, preferably some bs gui thing
+1. get clik with visualization to work in a ubuntu22 docker - DONE
+2. write down the installation process in a Dockerfile - DONE
+3. make the container more user friendly: - DONE
+  --> use build-user.sh from markus' ros-containers repo to create a user - DONE
+  --> folder with some basic goodies like a .bashrc or .zshrc - DONE
+  --> some text editor, preferably some bs gui thing - will just use vim instead
 4. create a single loadable docker image however you can
 
 the secondary goal is to re-do the documentation and
@@ -22,7 +22,7 @@ then just do the pareto optimal code rewrite to make it cleaner
 
 goal 2: clean up the code
 ---------------------------
-1. do all reading and updating into the local class in the step() function --> remove the rest
+1. do all reading and updating into the local class in the step() function --> remove the rest - DONE
 2. fix logging a bit (add a function which combines logs of different runs 
                       of a 'session' or at least names all logs in a run)
 3. stop doing minor bs asap
diff --git a/build-user.sh b/build-user.sh
deleted file mode 100644
index 7d92295eb002919ec89f9cb56ba182a4a9cddcb9..0000000000000000000000000000000000000000
--- a/build-user.sh
+++ /dev/null
@@ -1,5 +0,0 @@
-#!/bin/bash
-
-echo "student ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
-echo "groupadd -g $(id -g $USER) $USER" >> create_user.sh
-echo "useradd $USER -u $(id -u $USER) -g $(id -g $USER) -m -s /bin/bash" >> create_user.sh
diff --git a/create_user.sh b/create_user.sh
deleted file mode 100644
index edb46b17ac5e616c8e6b6be7ea9194c5663d0339..0000000000000000000000000000000000000000
--- a/create_user.sh
+++ /dev/null
@@ -1,34 +0,0 @@
-echo: echo [-neE] [arg ...]
-    Write arguments to the standard output.
-    
-    Display the ARGs, separated by a single space character and followed by a
-    newline, on the standard output.
-    
-    Options:
-      -n	do not append a newline
-      -e	enable interpretation of the following backslash escapes
-      -E	explicitly suppress interpretation of backslash escapes
-    
-    `echo' interprets the following backslash-escaped characters:
-      \a	alert (bell)
-      \b	backspace
-      \c	suppress further output
-      \e	escape character
-      \E	escape character
-      \f	form feed
-      \n	new line
-      \r	carriage return
-      \t	horizontal tab
-      \v	vertical tab
-      \\	backslash
-      \0nnn	the character whose ASCII code is NNN (octal).  NNN can be
-    		0 to 3 octal digits
-      \xHH	the eight-bit character whose value is HH (hexadecimal).  HH
-    		can be one or two hex digits
-      \uHHHH	the Unicode character whose value is the hexadecimal value HHHH.
-    		HHHH can be one to four hex digits.
-      \UHHHHHHHH the Unicode character whose value is the hexadecimal value
-    		HHHHHHHH. HHHHHHHH can be one to eight hex digits.
-    
-    Exit Status:
-    Returns success unless a write error occurs.
diff --git a/old_note b/old_note
deleted file mode 100644
index cdb0c63aa0e2c28ac323ec7ae13d6898a5e194ba..0000000000000000000000000000000000000000
--- a/old_note
+++ /dev/null
@@ -1,30 +0,0 @@
-
-1. do a writing demo
----------------------
-- use pinocchio to get fast inverse kinematics and dynamics -> done
-- ensure some sim/visualization works -> need to recompile some urdf to get the visual stuff
-- use/redo albin's code so that you have the same thing 
-	- read and understand (without all the theory) what is going on
-	- make an implementation roadmap
-	- implement
-- try out built-in ur force control
-- get a nice drawing input interface on some touch screen 
-- do tests so that you know it works
-
-2. implement all algorithms up to force control via velocity inputs
------------------------------------------------------------------------------
-- do as the title says
-- impedance control done by students in project
-- some basic pushing done by other students
-
-3. can the gripper drop and catch long objects?
-------------------------------------------------
-- you literally don't even need to control the arm for this
-- the key points to check are:
-	- can you do force control with the gripper,
-	  i.e. in any way (obv thru hax) get it to hold sth with a certain force
-	- see how fast this is
-
-
-3. write and test hold + flip 
----------------------------------