Demo 3: The Conversation¶
The third demo introduces collaborative work and devices with sensor-driven behavior. The objective is for each student to build a device which carries out a conversation with their partner’s device. For our purposes, the essence of a conversation is a turn-taking social behavior mediated by tactile communication. The behavior include can also elements strictly for human observers which aren’t sensed by the partner device.
Please keep your goals simple and commensurate with your skills. But please also help teach your partner skills if you are more experienced.
At minimum, the pair needs to agree on the physical interface with which the devices will signal each other. Pairs can also share implementation technique, design files, core code, etc., but each person is responsible for designing, fabricating, and programming their own work.
As before, the primary deliverable is a live in-class demo at the start of class on the due date, along with a brief blog entry.
Objectives¶
Negotiate a mechanical protocol for signaling events.
Create a simple mechanical structure which can produce time-based performance.
Create a sensor interface for tactile signaling (e.g. microswitch or photosensor coupled to mechanism).
Program a turn-taking behavior.
Use laser-cut parts and robust construction technique.
Deliverables¶
In-class demo at the start of class on the due date.
Brief blog entry including:
A brief video clip of the mechanism in action.
SolidWorks files as an attachment.
Arduino code.
A brief paragraph outlining the expected emergent behavior. If the actual behavior is different, please provide critical commentary on your assumptions.
Prompts¶
There’s an old joke in robotics: people have a bad habit of anthropomorphizing robots, and the robots really hate that.
Or as John McCarthy wrote in 1983, “Keep in mind that [a] thermostat can only be properly considered to have just three possible thoughts or beliefs. It may believe that the room is too hot, or that it is too cold, or that it is ok. It has no other beliefs; for example, it does not believe that it is a thermostat.” (“The Little Thoughts of Thinking Machines”, John McCarthy, Stanford, 1983, http://www-formal.stanford.edu/jmc/little.pdf)
So let’s not worry much about the content of the conversation; a machine which waits for an input, computes something, and then signals back is performing social behavior at the level of the thermostat. For our purposes, if the signaling is physical and visible, it is also likely to be interpreted by a human as the performance of a conversation. Any additional behavior performed beyond the minimal interaction will likely enhance this perception, even if is secondary to the internal state of the machine.
Many variations of tactile interface allow a human to interpose their own body in the exchange and thus become a participant in the conversation. This experiment would then make the extra behaviors more direct communicative, at least in one direction.
A few specific suggestions on interfacing:
A hobby servo lever could directly press on a microswitch at a specified height. (The devices will need careful placement.)
One or other of the machines could roll forward and bump a switch..
Each device could hold the ends of a pair of strings, one for tugging, one for sensing.
Each device could hold the end of a single string used for bidirectional signaling. (More challenging, with arbitration problems.)
Each device could use moving flags to modulate light falling on the opposite photosensor. Although the light itself is not ‘tactile’, it would be physically mediated communication visible to humans and amenable to interposition.
Criteria¶
No specific tempo is indicated, but if the conversation occurs too fast or small for us to see we’ll need high-speed video of the result.
You may use either the hobby servos or DC motors, but getting experience with the DC motors is recommended.
The sensors must be able to be activated by the mechanism itself, not just used as a human user interface.
The devices must actually use the sensing to control behavior; no time-based simulation.
The behavior has to be able to continue indefinitely, no one-shot exchange.
Glue is discouraged, I want to see sturdy construction which can be disassembled and repaired.
Other rules are the same as before: live demo in class; cite any sources; properly embed video; make links active; properly format inline code.