Simple Educational Robot Arm with Inverse Kinematics

The point of this project is to test a lesson that covers the theory and construction of a simple, two degree of freedom robot arm that moves in a plane and is controlled by specifying the X and Y position of the end of the arm (the 'hand'), rather than by specifying the angles of the two servos directly.

I ran most of this lesson last year at a summer camp, but due to limited time/high variance in math background of the students, we weren't able to reach the point I wanted to reach. (Really what happened is that I volunteered to have another class join my class for three hours for an activity, which meant a lot of my prep time ended up being soldering leads on more potentiometers...)

This activity seemed promising so I went through it again, at a less hectic pace this time, to try and make a list of the tricky 'gotchas' that would be useful to provide as hints if the goal was to have most of the students complete the project in the class time allotted.

Students who have completed a class covering trigonometry should have sufficient mathematical background to cover the math, which is described nicely on this page: http://www.learnaboutrobots.com/inverseKinematics.htm

A partial list of the tricky parts students may get stuck on (beginners tend to try to build the whole thing at once; a few compound problems can make it very difficult to debug):

• Constructing the arm so it is sturdy enough to last until demonstration time.
• Including math.h and finding documentation for C trig functions
• Keeping track of radians vs degrees
• Measuring link lengths accurately and setting up the physical arm to match the model (the arm should physically be perfectly straight  line if both servos are at their max range
• Mapping the analog inputs (reading from the potentiometers) to a reasonable range of the X and Y axis, in accordance with the units chosen for specifying the link length in the code
• Dealing with floating point error--floating point operations are not the optimal solution here but the goal here is to avoid adding more complex C programming concepts onto an already dense lesson. See the code for more detail. A good summary of the issues can be found here: http://www.engblaze.com/faster-code-fridays-avoid-floating-point-math/
• Using a separate power supply or filtering the Arduino power supply. The arm can otherwise get stuck in a cycle where servo moves, drawing a lot of power momentarily, which causes the analog inputs to jitter (and the onboard LEDs to flicker), which causes a new reading which causes the servo to move... Most students will use the separate power supply if it is provided, but it is also common for students to forget and tie everything to a single rail.

Here's an illustration of an issue that will happen if the student mounts the second link so that it cannot fold inwards. The green area on the left shows where the end of the second link (the 'hand') can reach. The shape is awkward to navigate. The right hand side shows the area reached by a better choice of angle limits for the second link. If it can fold inward, similar to how a human forearm/elbow/upper arm works, then it is easier to use. (This image assumes links are equal length).

I did mount the second servo flipped downwards, to reduce overall height of the assembly. That was a mistake in hindsight, because it means the arm can collide with itself.

Here's a video of the test arm I built, demonstrating that it more or less works correctly.

Finally here's the sketch. It isn't clean or commented...but I've decided it is better to share these things than to never get around to it at all.

Arduino Sketch for this project

Three wheeled robot simulation

I made a simple simulation to figure out how to orient the wheels of a 3 wheeled robot with independently steering and driving wheels based on a desired instantaneous center of curvature (ICC).  It makes a lot of assumptions (perfect point contacts of the wheels with the ground, no slippage allowed, etc) but is a useful conceptual tool.

Get the latest version here:
https://github.com/eshira/wheelsim (uses Python, numpy, and matplotlib)

The triangle represents the frame. The view is a bird's eye view. Each wheel is mounted on short extensions that pivot about the frame at the vertex of the triangle.  The colored lines are the perpendicular lines to the wheel. Where they meet, a red dot denotes the instantaneous center of curvature, or ICC. The black circle denotes the motion of a point in the middle of the robot.

Below the ICC is at the bottom of the robot frame, marked by the red dot. Points on the robot that fall on the perimeter of the black circle, will move along the black circle if the wheels are driven at the appropriate velocities.

To describe the motion of any particular point on the robot frame, just imagine a circle concentric with the red dot that passes through that point on the frame. The relative linear velocities of the wheels can be described by the relative perimeter lengths of the circles that pass through their center.

Below, we restrict the wheels to only 170 degrees steering rotation (remove 5 degrees from end of range on each side). This creates the red areas, which are places the ICC cannot be without forcing the wheels into the disallowed steering rotations.

The red lines pass through the pivot point of the steering of each wheel. To avoid intersections with the robot frame, and because typical servos only support 180 degrees of rotation anyway, the wheels are mirrored if they pass that boundary. To avoid discontinuous driving caused by having to stop to flip the wheel over to the other side, avoid having the ICC cross this boundary.

Here we have parallel line driving (near vertical direction, along the black line). In this situation, the ICC is very far away. The perimeter of the black circle therefore appears to be completely straight. The wheels are all parallel. The colored lines represent the normals to the wheels, which intersect at the ICC, as they are not quite parallel.

Note that the purple wheel is probably going to collide with the frame if we try to drive straight in the direction of the top tip of the frame. It is probably better to drive as shown below instead.

Above the robot drives along the black line shown, horizontal to the image.

Corrections can be made by turning 'left' and 'right' as shown below.