Sixi robot arm

https://www.patreon.com/posts/progress-report-29427189

New OSHPark PCBs arrived

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

With this we can finally finish the hardware preparation for shipping units, after which we can also get a final bill of materials and start to package DIY kits.  There will be two flavors:

• DIY kits with all the non-printable parts.
• DIY kits with everything, including the printed parts.

Collision detection

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

The software only lets each joint of the robot move within a safe range to prevent wire twisting or other potential damage.  That piece of code does not consider the angle of joint A in relation to the value of some other joint B.  So it was still possible to make the arm hit itself.

This new collision detection code prevents each bone of the arm from colliding with other bones of the arm.  At present it is a crude collision detection system, using only the box around each joint.

Also now that these boxes have been calculated, the center of each box is known.  the mass of each bone can be pulled from the Fusion360 model, and then a point-mass physics model can be created to simulate forces like gravity.  This gets us closer to dynamics like push-to-teach and telling the arm "please push on this item with a force of N newtons"

Next

Next we'll be assembling the new shoulder design with the PCBs that should allow us to unplug the umbilical from the arm and the control box.  I'm thinking Twitch stream?  Maybe just a Youtube Live, given the recent Amazon protests.  Choice of evil companies... hmm...

I have recording and playback mostly working now.

Firstly, I build a class to contain a recording.  Then I decoupled an input event like a button press from the action that should result.  instead of

button push -> do thing

it is now

button push -> recording middleman -> do thing

then if recording is on, button pushes are saved.  if playback is on, button pushes are ignored and instead the recorded value is used.

The last part that still bugs me is changing tools.  As before, there is a list of tools obtained by using a ServiceLoader and I don't know what to do if, on playback, the ServiceLoader doesn't find the matching tools.  Oops!  I believe the easiest will be to run the SL once at the start and build a table of tools, then refer to them by index.  that means on file start we can check all files are in place first.  It would be extra clever if those tools had a URL so that they could be found by an automatic install system....but that's a tomorrow problem.

The good news is that I can play back and record robot movement and robot tool behavior.

I do not yet have a way to recording adding and removing robots, or moving whole robots (base frame of reference).

I have a more serious challenge dealing with GUI clicks that change the tool on the robot.

In Java, as I understand it, the main render loop is in a thread and GUI click events are in another. 

On GUI click , I use a ServiceLoader to enumerate classes derived from DHTool available for my robot, then setup an undoable event to change the tool on the robot.  This action could happen at any time, which makes recording the tool change events (in the render loop) as a stream unreliable.

if I use the enumerator to create an array of possible tools and store them in the dhrobot then they have index numbers (easy to say "current tool=x" in the stream).  This add a problem that if a new tool is added i have to be careful to not change the old index numbers.  Seems unreliable - I can see future me changing the tool order on a whim and breaking other people's recordings.  On the plus side, it solves the reliability problem - a button click makes a *request to change tools*, and the tool change actually happens in the render loop immediately after the request is recorded/played back.

Also i'm not sure how the undoable action system would work with a recording.  if the recording is played back, what does that do to the undoable sequence?  What if I play the same recording 50 times?

The last option is to disable tool change completely during recording and playback, but I still need a way to set the tool once at the start of the recording. ...but if I can set it once in a recording I might as well let the user do it whenever they like.

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.

Demo

Here's our instagram demo of movement on all six axies. 

https://www.instagram.com/p/Bx0L-QCHveS/

We'll update this post with the 2kg payload demo as soon as I finish editing footage.

Buy now

The store page is now open at https://www.marginallyclever.com/product/sixi-mk2-robot-arm/

Expect at least 8 weeks to produce the first units.

Make your mark

We have open tickets on Github.  If you complete one of these challeges we'd be happy to give you a letter of reference and put your name in the developer credits. 

Software: https://github.com/MarginallyClever/Robot-Overlord-App

Hardware: https://github.com/MarginallyClever/sixi-2

Especially interesting to us are grippers and use-case examples.  Pour a beer!  PIpette in a lab!  fold a shirt!  Cut Mr. Bond in half!

After months of waiting my Tormach 770M has finally started to trickle in.  Three of five palettes have arrived.  I'm eager to start making cycloid parts from metal to improve our efficiencies.  See it here:

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

https://prize.supplyframe.com/ says Sixi 2 is now in 7th place at 40 skulls.  The number 1 place has only 97.  Just... just putting that out there...

Nice!  One step closer to building programs for the arm(s).