You have an idea for a small object that responds when someone shakes it. It might be a game piece, an exhibit prop or a classroom activity. Before choosing its final shape, answer a simpler question: can a person understand what the movement does, and recognize when the interaction has finished?
We built a small version of this on our bench to make that question concrete. An MPU6050 motion module supplies the input, a four-digit TM1637 display shows a result, and a vibration module adds feedback. The behavior was assembled from blocks in BIPES, a browser-based block editor for MicroPython, running on a Raspberry Pi Pico-based controller board.
The modules sit on a transparent mounting platform with the cables visible. You can follow each connection and compare the build with its program, which makes it a useful interaction prototype long before there is a handheld product.
Give each part one job
In our program, the MPU6050 uses I2C0 with SDA on GPIO4 and SCL on GPIO5. I2C is the two-signal connection used to talk to this sensor. The TM1637 display uses GPIO7 and GPIO8, and the vibration module is controlled through GPIO9. These are software GPIO numbers for this build, not connector positions to copy onto an unrelated board.
The platform holds the sensor, display and motor in a fixed arrangement. Keep that relationship while you change the interaction. If the sensor is loose, or the cable moves independently of the object, it becomes harder to tell what motion the person is actually asking the prototype to recognize.
Arduino's September 2026 Reflexes Machine project is a useful comparison: its appeal comes from coordinating the start of play, the buttons and the feedback. It uses different hardware. The goal here is smaller: connect one movement to one complete response.
Follow the sequence the program actually runs
The block stack reads from top to bottom: initialize the modules, read three gyro channels, test a threshold, choose a result, animate the display and pulse the motor. The saved project and the generated code tell the same story.
The loop reads the three gyro channels. If any reading is greater than 30, it picks a random result from 1 to 6. It then shows ten temporary numbers, 200 milliseconds apart, before showing the chosen result. In outline:
repeat:
read gyro x, y, z
if x > 30 or y > 30 or z > 30:
pick a result from 1 to 6
show 10 changing numbers, 200 ms apart
show the result
pulse the motor once per point of the result
The motor pulses after the final number appears, once for each point of the result: a four produces four programmed pulses. Each pulse is 200 milliseconds off followed by 200 milliseconds on. Those are code settings, not timings measured on the hardware.
So the interaction is triggered by movement and then runs through a fixed sequence. It does not keep rolling until the user stops shaking, and it does not give different pulse patterns to different results. If you had imagined either behavior, it is not in this program.
The comparison also uses positive values rather than the size of each reading. A movement that produces a large negative reading may not trigger at all. Keep that in mind when you ask someone to try it; "shake it" is a broader instruction than the code's trigger rule.
Our video of the device shows it being moved and the display alternating between changing numbers and single-digit results. That is useful for seeing the scale of the prototype. How the motor feels, and whether triggering is reliable in every direction, need hands-on checks; the display alone cannot answer them.
Decide what a second shake should do
The display animation and the vibration both use waits. While that sequence runs, the main loop is not reading the gyro. If a person shakes again immediately, should the game ignore it, restart, or queue another turn? Choose the rule before shortening delays or adding more effects.
A focused next test compares a brief movement, repeated movement and a movement during feedback. Record what the person did and what the display did next. If you want a direction-independent trigger, or an explicit "return to rest" stage before the next turn, treat that as a program revision and record it separately from the first version.
Keep the BIPES project file together with the MPU6050 and TM1637 libraries it imports, the board profile and the pin map. The block file alone does not guarantee that a freshly flashed board can run it.
What to settle before the enclosure
Once the interaction makes sense, a smaller enclosure, a power source and secure module mounting become meaningful next steps. Moving the sensor or changing how the object is held changes the motion the program sees, so repeat the movement trial in the new arrangement.
The open platform has done its job if it separated the behavior worth keeping from the packaging still to design. When you hand the idea to someone else, send a short video and a written rule for what one shake, a repeated shake and a shake during feedback should do. That rule is what a later firmware revision will be judged against.