News

Friday Facts 3

This week I’ve done a lot to make driving the Sixi 3 arm easier.

You’ll recall from FF1 that I had build a Panel to talk to a robot in Javax Swing.

TextInterfaceToListeners (at the bottom) was the starting point. Then I made a ConversationHistoryList (in the middle). The two are tied togeter in a TextInterfaceWithHistory, such that hitting send copies the message to the history and clicking a line in the history copies it to the input field. Next I made a ChooseConnectionPanel (at the top) and attached that to the TextInterfaceWithHistory inside a TextInterfaceToNetworkSession. Sure, it could have all been in one giant class… but that’s hard to manage, debug, or reuse.

Having made all that, I found it was no better than the existing Arduino serial interface for talking to the robot. My biggest worry is that I make a typo and send the robot crashing through the table before I can hit the emergency stop. So to address this pain point, I needed a way to drive more intuitively.

The Dial

The Dial is drawn to scale whatever size you need. It listens for scrolling of the mouse wheel. Other classes can subscribe to get ActionEvents when the dial moves. This way the dial is loosely coupled and can be reused all over the place. For example,

Angle Driving

Using the dial I built a panel that is initialized with a virtual sixi3 robot.

The radio buttons on the left are pulled from the robot model. The AngleDriving system listens to the dial. When the Dial moves then AngleDriving looks at the selected button, finds the robot joint, and tweaks it by 1 degree.

Cartesian Driving

Moving the arm one joint at a time is fine some of the time, but sometimes I need to move in a straight line. I improved the look of the Dial a little bit and made this tool to move the end effector (finger tip) of the robot arm.

XYZ are straight line moves. Roll is a twist around Z, pitch a twist around X, and yaw a twist around Y. Each of these moves happens relative to the reference frame. The options for now are world, the first joint of the robot, and the end effector itself.

Read-only panels

Once I had that I needed more ways to visualize what the system was doing. The two types I made are the AngleReportPanel,

And the various matrix reports.

Each of these listens to the robot reporting a change to the end effector position.

Cartesian Driving with Jacobians

Big shout out to https://akintokinematics.com/ for the excellent Jupyter notebooks that helped me improve cartesian driving to work. For some time now I’ve been telling everyone how much I love Gradient Descent for moving the robot arm. Well… it turns out Gradient Descent is hard to tune and slow AF to converge on a solution, sometimes taking 30 seconds per millimeter. So, instead, based on Greer’s notes, I used the approximate Jacobian.

The approximate Jacobian is a matrix describing the relationship between joint velocity and cartesian velocity at a position. So from position A to position B have the cartesian difference {x,y,z,roll,pitch,yaw}, dAB.

  • I get the approximate Jacobian at A, aj.
  • I get the inverse or pseudoinverse of the Jacobian, aji,
  • Multiply aji * dAB to get is the amount to move each joint in the arm.
  • Apply the joint change and measure the error term.

I set up a loop to run (at most) 20 times. In practical terms it never seems to run more than 2 or 3 per step, and feels blazing fast.

Putting it all together

If you run the development version of Robot Overlord today and use Demos > Sixi 3 you’ll get this view and be able to drive the virtual robot by playing with the controls. Tweaking the dials moves the virtual robot. Sixi 3 UI listens for those changes and sends them through the RobotUI.chatInterface so they show up in the history and they move the real machine (if connected).

My next Thing is figuring out a nice way to run programs: loops, sequences, patterns, wait for signal, send signal, conditionals, and so on. The virtual robot does not know anything about gcode and my gut says it would be a really big mess to spread gcode around the app. I would love to jazz with you about this and find a Good Way to achieve the Thing.

News

Friday Facts 2

This last week there has been work on Makelangelo software to make it work with the new firmware.

I spent a lot of time using design patterns to decouple classes so they can be independently tested. Usually this means an Observer pattern common in Java: a visible Panel on the screen has a list of registered Listeners and when something interesting happens in the Panel it calls notifyListeners(interestingEvent). This way Panel can be run and tested without needing any specific Listener.

A single sub-panel

I’d like to change up the code for a MakelangeloRobot to be decoupled from the NetworkSession – the source of data from the real machine. Then data could come from, say, a piece of code reading from a file. That way the state of the machine could be recorded and played back for testing things like “is the machine connecting to you a Makelangelo 5, a 3, a 2, or something else?”

I’m also plagued by ideas about how a Turtle path is used by a MakelangeloRobot. Turtle is a class that contains TurtleMoves, which describe the movement of the pen over the paper. One Turtle per color! Based on the old Commdore 64 turtle, one of the first procedural drawing programs I used as a kid.

Many classes in the Makelangelo app read and manipulate the history of TurtleMoves in a Turtle.

Drawing speed vs quality testing

In a cartesian plotter the velocity, acceleration, and jerk have the same effect everywhere across the work area. Testing such a machine to find ideal speeds is not onerous. I would draw a grid of squares and on the x axis each square would have more velocity while on the y axis each square would have greater acceleration. In this way the sweet spot is easy enough to find.

In a polargraph plotter the challenge is much greater. What works at the top doesn’t work at the bottom, what works in the center might not work on the sides. Simply drawing a set of squares isn’t enough! Long story short I need your help to find the sweetest of sweet spots. Together we can do it. Right? Right??

Spiral improvements

before
after

…and that’s all I have to say about that.

Final thoughts

These changes can be downloaded from the Makelangelo project on Github.

Did you know you can add bars to your timing belt? I didn’t.

Join our Discord to talk more about this post.

Makelangelo News Robot Arm

Friday Facts

This week I worked on the Sixi 3 arm quite a lot.

Coding

Monday, I made a new tool to talk to my robots. Arduino Serial monitor is all well and good but I needed more features and some color coding.

Sixi 3

Tuesday I tackled a problem with the base of the robot. When I designed the first version it seemed fine! Then I tried to drive it while in a Zoom meeting for the Vancouver Robotics Club and discovered that at the right spot the base and the J1 actuator collide.

Whoops. So I designed and 3D printed a new base…

…which didn’t work! The screws to attach the base to the board could not be accessed after the base was on the J0 gearbox. No tool clearance is bad! Taking the whole robot off the board just to fix J0 is bad! So that went in the recycling and I tried again.

That worked much better!

The screws that go on an angle through the top and bottom halves of the base need a nut. The nut can’t turn. I could make a really tight slot that the nut barely fits into… but then how do i get the nut out later? My solution is these nut holding tools. They fit snugly, prevent the nut from turning, and give me a convenient handle to grab with pliers when I need to pull them out. A gift to my future self!

Makelangelo 5

As you know from the previous post, there’s a new firmware coming that is faster, smoother, and much more friendly to all they DIY people out there. Much of this week has been talking with people on Discord, showing them how to set up their custom versions. In short,

  • Install the apps mentioned in https://mcr.dozuki.com/Guide/How+to+upload+Makelangelo-firmware+from+Windows+(2021+)/33?lang=en
  • Get the firmware currently at https://github.com/i-make-robots/Marlin-polargraph
  • read Marlin/Configuration.h and change where needed for your board, your drivers, your LCD.
  • For size changes and more advanced stuff, come talk with us!

I’ve also filmed raw footage about how to use 3M hooks to put a Makelangelo on a flat wall. Some people don’t like the suction cups or they don’t have a big window. No problem! Subscribe to my Youtube channel and watch for the announcement.