3.5. Tech Demo 3: Mechanism

This third demo is an exploration of the interaction of physical mechanism and computation. It is structured as a two-week mini-project to be developed in pairs. You have your choice of partner.

3.5.1. Deliverables

  1. The first deliverable is a brief progress report documenting an initial proof-of-concept demonstration. The form is a short (less than 1 minute) video documenting the operation of the demo, posted via the 16-223 WordPress site.

    This demo should reflect meaningful progress on either the mechanical or computational elements of the result. It is termed proof-of-concept to suggest that it should resolve a key open question or area of difficulty. The specifics will vary considerably depending upon the objective and the experience of the teammates.

  2. The second deliverable is short report documenting the final result, delivered as a post including another brief video, the Arduino code, a brief paragraph describing the key features of the implementation, and photographs of mechanical details as appropriate.

    If your Arduino sketch is a single file, please post your code inline, using the code tags described on the site help page, as unformatted code is very hard to read. If it includes multiple files, you may either post them inline or as a zip. Do not post your code as images.

    Please observe the Lateness Policy and Fall 2017 Calendar. Please add your post to the ‘Demos’ category.

3.5.2. Objectives

The goal of this project is to create a simple laser-cut mechanism controlled by an Arduino program. The mechanical elements should demonstrate structure, freedom of movement, and (optionally) power transmission. The computational elements should demonstrate sensing, actuation control, or a combination of both. The laser-cut material could be cardboard, acrylic, paper, or thin plywood.

There are a number of directions this demo might take. A few suggested starting points follow:

  1. A sensor mounted on an actuated pivot joint. This extends a single-point sensor into a line-scan sensor.
  2. A papercraft or origami form with hinge joints, moved by a hobby servo.
  3. A physical pendulum pumped by intermittent actuation. The actuation could use a solenoid or hobby servo to tap the pendulum at regular intervals. One key is creating a low-friction pivot for the pendulum.
  4. A human-operable physical control such as a slider or lever whose movement can be sensed.

Ground Rules

Solutions involving moving parts supported solely by the hobby servo spline shaft are disallowed. The servo shaft is not designed to support static loads, and this approach is the cause of many servo failures and flimsy demos. A much better solution is so provide a hinge point or sliding interface in the mechanism which supports mechanical loads, and then attach the servo using a linkage of plastic or piano wire.

Another temptation is to use a stepper motor as both an actuator and a set of joint bearings, since it has a steel shaft well-supported by internal bearings. This does work for light loads, but it’s a limited approach and won’t help you learn how to decouple passive mechanical loads from actuated loads, so this is discouraged.

The integration of computing should complement the physical process, either to sense or control it. The program could be quite simple, e.g. generate a fixed pattern of actuation over time. Or it could more advantage of the potential computation and filter or record data from the device. If you are ambitious, you could use both sensing and actuation to apply feedback control to regulate a mechanism.

3.5.3. Criteria

Please observe the following:

  1. The emphasis is on basic mechanical design. The key functions are structure to connect multiple components and freedom to provide articulation. For freedoms we will generally use pivoting or sliding joints. Other functions to consider are power transmission which couples actuators to freedoms, and protection from the environment.
  2. You may use more than one input or output if it makes sense, but it would be expedient to keep it simple.
  3. The device should actually work; no faking.
  4. Please clearly cite any sources. It’s fine to use libraries or modify code you find elsewhere as long as they are clearly credited.
  5. Please embed your video so it can be watched directly from the post. The easiest way to do this is to host it on a third-party site. Videos hosted directly on the course site should be .mp4 files and use the appropriate video shortcodes. N.B. hosted QuickTime .mov files cannot be embedded.
  6. Please make all links active. Just pasting in a URL does not necessarily make it clickable.