https://www.instagram.com/p/BzJCEoRneay/

A short demo of improved kinematics.  I built v1 following the few Youtube videos I could find and, sadly, they didn't cover every edge case.  After much searching I found the answer for all cases and now movement appears to be sane.

https://www.instagram.com/p/BzJiO7RHKln/

Also added a gripper made just to hold a beer can.

Decimating models

Models exported from Fusion360 in STL format have millions of triangles, many of them completely hidden inside the robot.  They slow the loading time, the render FPS, and reduce the total number of arms that can be simulated at once.  The single biggest culprit are the threads on screws and nuts.  So here's a quick screencast of how I do a quick & dirty cleanup of my Fusion360 models.

https://autode.sk/2YehWKk

The original files were 102mb on disk.  The new files are 3.5mb.  The simulation loads a Sixi2 in about 2 seconds and now it just feels *snappy*.  Worth it!

Recording & Playback

Ok, this part is where I need advice and help.  The main loop of the application is driven by the screen refresh at 30fps.  Every time the screen is redrawn I also sample the input devices to move the arm. 

I could record & playback the input directly if I thought the framerate would stay at 30fps with high fidelity.  The input recorded would only be good for moving the simulated arm; a post-processor would have to turn it into gcode and send it to the actual robot.  Recording input also breaks if the input configuration is ever changed.

recording the post-process gcode is do-able.  Then I would have to make the post-processor work both ways.