• Do the inverse kinematics,
• Check the bounds,
• Improve the kinematics.

This is a fancy term for “calculating the joint angles required to achieve a given tool position”. In our case the tool is the ball. I found a good guide to the maths at Applied Go. It's just some fancy trigonometry to calculate the angles for both arms. In order to integrate this logic with my specific robot I had to account for the fact that arm 2 rotates WRT arm 1 while arm 1 is moving.

An interesting and non-obvious (to me) fact I discovered during optimisation is that the two angles calculated for the joints are interchangeable if your arms are the same length. You can apply either angle to either joint and the tool position will be the same. I used this to my advantage when assigning the rotations to the stepper motors. The angles were assigned to the steppers based on which arrangement would result in the least total movement.

I wanted to make it impossible for the tool to hit the edge of the enclosure. I could depend on GCODE for this, but I would rather be able to account for silly coordinates and still prevent a crash. To solve this I implemented a system to filter every coordinate to ensure it is safely within the bounds of the octagon. I first check to see whether the point is inside - this is pretty straightforward for convex polygons. If the point is outside the octagon search for the two vertices that are closest to the point, then I find the point on the line between the two vertices that is closest to the target point. I then remap the target to this closest point.

This worked really well, and it should support many different types of convex enclosure shapes via the constants.ENCLOSURE_VERTICES list. However concave enclosure shapes are considerably more difficult, both in terms of bounds checking and also path planning.

In these cases I would probably rely on the GCODE to prevent crashes, since solving a pathfinding problem at runtime on a microcontroller would be hard.

• Build the electronics.