News Robot Arm

Robot Overlord : New 3D Manipulator Controls

After nearly a week of screaming at my monitor, I finally got a new system for rotating and translating Sixi2’s hand.

The old method used…

  • mouse LMB for XY translation
  • SHIFT+mouse LMB for XY rotation
  • ALT+mouse LMB for Z translation AND Z rotation

Which (technically) worked, but was super hard to do well.

technically correct

The new system is much easier

  • Double click the robot you want to move and the translate tool will appear.
  • Hover over each handle and it will change color. Click and drag the active handle to drag the robot’s hand. If the robot cannot move the angry joint will turn white, then red.
  • Hold shift to replace the translate tool with the rotate tool. Hover over each handle (the colored rings) and they will change color. Click and drag on the handles to rotate the robot’s hand.


In the future I may even remove the need for the shift key so that everything can be done with a mouse or a touch pad or maybe even a sip+puff.

I tried several things that didn’t work out, like using OpenGL’s Select Buffer. I also notice the rotation handles don’t stay inside the grey circle when they are in the far corners of the screen and I don’t have an answer for that yet.

If you want to read the code in the open source project, start in org.marginallyclever.robotOverlord.DragBall

Also much love to Their 3D graphics tutorials kept coming up when I searched for things I needed in Robot Overlord. If you want to learn 3D graphics it is a clean, simple, effective resource.

Robot Arm

Intuitive robot programming

While making demos of what the Sixi arm can do I discovered that I’m a terrible driver. More than a few times I wanted to drive the hand +X and instead rotated the wrist, or got the direction wrong. It might not seem like much now but if it were holding a cup of liquid or in a narrow confine that would be very bad for the end user!

A good fix would be a way to preview a move before committing to that move, and maybe having some kind of undo feature. Now by moving the joystick the blue “ghost” arm moves while the yellow “live” arm stays still. When you like the pose you’ve reached, press X on the playstation controller to commit that move. If you want to undo – put the ghost back on the live arm – press the circle button on the playstation controller. Lastly if you want to drive the arm back to the starting position, triangle button will move the ghost to the starting position and then X would commit the move.

Let me know in the comments how is your experience with driving the simulation. I will be dedicating the next few weeks getting ready for the Vancouver Mini Maker Fair, September 14, 2019 at Science World.

News Robot Arm

Robot Arm Study 5 in Robot Overlord, Tool mounting design

I’ve got Study 5 working in Robot Overlord.  The STL files are heavy in detail so the load time is long, but it works.  Forward and Inverse kinematics as good as any other arm in the system (which already includes the 7bot, MANTIS, and others).  I still don’t have enough time to rip apart the inner workings and rebuild it with a record & play back mechanism.  That would be very nice…

Also here is the hole pattern if you want to design a tool that fits on the wrist of the robot.  I would love to see someone design an Automatic Tool Changer (ATC) so the robot could put down one tool, pick up another, and use any tool it is currently holding.


Robot Overlord: THOR added

As I just wrote on the THOR project page, Robot Overlord now supports inverse and forward kinematics for the THOR robot.  One by one they all fall under my dominion!  MwahahahHAHAHAHAHhahahaha…..aha…


Robot Overlord: Thoughts on building robot programs

Programming robots visually is proving to be a big challenge. I thought I laid all the ground work but now I’m not so certain.

Each derivation of Robot has a derivation RobotMotionState (a snapshot of the robot at a moment in time). By comparing RobotMotionStates I hoped to test for robot/robot collisions.

I’ve also got a system to command a robot to move, which changes the RobotMotionState, checks that it’s internally valid (robot can reach that far) and externally valid (doesn’t hit anything in the world).

I’ve been stuck for months trying to build a system of RobotPrograms. Something like the Adobe Premiere or Flash timeline, where blocks of time have one command each. I couldn’t wrap my brain around it enough to come up with generalize-able cases that could be written once and work for all robots.

In a dream last night I flipped things around a bit. What if a timeline has keyframes and each keyframe is a RobotMotionState?

  • Move the timeline to a new position, move the robot to the new state, keyframe is automatically created.
  • Move to an existing keyframe, adjust the robot, done.
  • Delete an existing keyframe.
  • Drag a keyframe along the timeline.
  • Clone a keyframe.

Ideally there should be a way to interpolate between two RobotMotionStates. That way as the read head is moved along the timeline the robot(s) move between their states. There must also be a way to calculate the difference between two RobotMotionStates and send *just that change* to the robot as a command.

Oy. I’m not sure this is any easier.