An exhibit that wakes up when someone approaches can feel inviting. But "someone is here" can mean several things: a visitor has walked past, stopped to read, or stayed in front of the display. Before choosing an animation, decide which of those events should start it.
An artist ran into exactly this in an October 2018 Arduino Forum discussion. The first request was for a display controlled by human presence. Later the artist clarified that a person might stand still, and that the display should tell a person from an object. Those extra conditions changed the sensing problem completely.
We started with a narrower bench experiment: a PIR motion module and an LED, wired to a Raspberry Pi Pico-based controller board and programmed with blocks in BIPES, a browser-based editor for MicroPython. It gives a visible way to connect the sensor's digital output to feedback before building a larger installation.
First make the signal visible
The PIR module's signal goes to GPIO9, and GPIO7 drives the light. The program reads the input with a pull-up enabled. GPIO numbers refer to software signals; confirm them against the board and module labels before reproducing the wiring.
PIR is a motion-sensing approach. Panasonic's PIR guidance discusses detection patterns and installation position; those specifications are for Panasonic's parts, not for the module we used. For the prototype, treat the output as a trigger signal to observe, not as a count of visitors or proof that a stationary person is still there.
The logic is short enough to follow without knowing Python:
repeat:
if the PIR input is high:
print a trigger message
wait 200 ms
turn the LED on
otherwise:
turn the LED off
The console showed the trigger messages alongside this program. There is no five-second off-delay and no buzzer in it. If the light stays on for a while after someone passes, that hold time comes from the sensor module itself, not from the application. Keep those two apart: a hold time you did not program can change when you swap the module.
This simple program is useful for a first signal-to-light check. It lets you change one thing at a time, such as the sensor position, the approach route or the response rule. A complicated animation would make those changes harder to see.
Choose when the interaction ends
For a short welcome effect, you might want a trigger to start a fixed animation and ignore new triggers until it finishes. For a reading light, you might want it to stay on for a chosen interval after the latest trigger. Neither rule exists in a level-following program like this one; each has to be written deliberately.
Write down what should happen if another person arrives while the effect is playing. Then test:
- approaching from the expected direction;
- walking past without stopping;
- standing still in front of the display;
- leaving.
Record the sensor signal as well as the visible output. Otherwise a change in the module's signal can be mistaken for an error in the display program.
Test in the real position early
Mounting belongs in that test. Use the planned sensor position and viewing opening as early as practical. Our bench platform keeps the module exposed and easy to reach, which is helpful for experimenting but very different from hiding it behind a display housing, where the opening, angle and material in front of the sensor all change what it can see.
If the experience depends on continued presence, distance, or telling a person from an object, write that requirement down before selecting the final sensing method. PIR may not be the right part for it. The small light experiment still earns its place: it makes the gap between an input event and the visitor experience you actually want visible.
When you hand the idea on, include a sketch of the installation, the route visitors will take and the rule for when the effect starts and stops. Those three things decide the sensor choice more than any module datasheet.