01 / THE RESEARCH QUESTION
How do you design an object that can sense its environment and respond appropriately?
My experiments in embedded systems began with a simple framework: identify what an object needs to know, select an appropriate input, process that information, and determine what physical response should follow.
This shifted electronics from component-led experimentation towards behaviour-led design.
PHYSICAL EVENT
↓
INPUT — What needs to be sensed?
↓
PROCESS — What does the information mean?
↓
DECISION — What should happen?
↓
OUTPUT — What creates the response?
↓
FEEDBACK — Did the action happen correctly?
02 / INPUT — WHAT DOES THE OBJECT NEED TO KNOW?
For an automated cat-litter system, the first requirement was to determine whether the cat had finished using the box.
I initially fabricated and programmed a board using a PIR sensor. The sensor successfully detected infrared changes caused by living beings—but that was precisely the problem. It could detect activity nearby without reliably establishing whether the cat was actually inside the litter box.
The electronics worked. The sensing logic did not match the behaviour I needed.
This led to an ultrasonic sensor, where distance could provide more spatially specific information about presence within the box
SENSOR SELECTION
PIR
Detects nearby movement/presence
↓ unsuitable for this application
ULTRASONIC
Measures distance
↓ better information
CAT PRESENT / CAT EXITED
03 / OUTPUT — WHAT SHOULD THE OBJECT DO?
The required output was mechanical: a rake needed to travel across the litter bed and remove waste.
My first output-device experiment used a DC motor. It worked, but the final mechanism required greater control over position and movement.
Experience with stepper and servo actuation during machine building suggested a better combination: stepper motors for controlled linear travel and a servo for the rake mechanism.
REQUIRED BEHAVIOUR
Move rake → control position → perform cleaning action → return
↓
DC MOTOR
Movement ✓
Position control — less suitable
↓
STEPPER + SERVO
Controlled travel + controlled mechanical action
REQUIRED BEHAVIOUR
Move rake → control position → perform cleaning action → return
↓
DC MOTOR
Movement ✓
Position control — less suitable
↓
STEPPER + SERVO
Controlled travel + controlled mechanical action
04 / COMMUNICATION — CONNECTING EVENT TO ACTION
Sensing and actuation only become a system when information can travel between them.
I attempted to network the input board directly with the motor-control system so that sensing the cat’s departure could initiate cleaning.
The intended configuration did not initially work. I eventually established communication between the input board and another microcontroller board instead. Fab Academy
The failure clarified an important distinction:
a working sensor + a working motor ≠ a working embedded system.
The behaviour exists in the relationships between them.
05 / INTEGRATION — FROM COMPONENTS TO BEHAVIOUR
SENSE → DECIDE → ACT → STOP
ShooBot became the system-integration experiment through which the individual exercises came together.
The final electronics architecture required an ultrasonic sensor, ATmega328P microcontroller, two NEMA 17 stepper motors with A4988 drivers, a servo, limit switch and status lighting. The ATmega328P was selected partly because the system required multiple programmable connections; my documentation records 23 programmable pins.
CAT ENTERS
↓
ULTRASONIC SENSOR
Presence/distance
↓
ATmega328P
Interpret input
↓
CAT LEAVES
↓
STEPPER MOTORS
Move rake
SERVO
Control cleaning mechanism
↓
LIMIT SWITCH
Detect travel boundary
↓
STOP / RETURN
06 / EMBEDDED SYSTEMS ARE PHYSICAL SYSTEMS
Integration revealed that embedded design could not be separated from mechanical and material design.
The sensor needed the correct position. Motors needed structural support and clearance. The rake needed controlled travel. Electronics had to remain protected from the cat. The sieve material affected the mechanical system. Limit switches depended on physical geometry.
Even apparently unrelated fabrication decisions changed how the electronics could function.
MECHANICS ↔ ELECTRONICS ↔ MATERIAL ↔ CODE ↔ USER
07 / WHAT THE EXPERIMENTS ESTABLISHED
01 / BEGIN WITH BEHAVIOUR
Define what the object must know and do before selecting electronics.
02 / A WORKING COMPONENT CAN STILL BE THE WRONG COMPONENT
The PIR detected presence correctly; it simply detected the wrong kind of information for the application. Fab Academy
03 / INPUT AND OUTPUT MUST BE DESIGNED TOGETHER
The useful unit is not sensor or motor independently, but:
event → sensing → interpretation → action.
04 / MECHANICS AND ELECTRONICS CANNOT BE SEPARATED AT INTEGRATION
Actuator position, structural geometry, material choice and sensor placement determine whether the electronic system actually works.
05 / FAILURE IS PART OF COMPONENT SELECTION
PIR → ultrasonic
DC motor → stepper
acrylic → perforated metal
failed print → revised print
Each failure reduced uncertainty about the system.
RESEARCH → CURRENT DEVELOPMENT
From embedded electronics to behavioural systems
These experiments established a way of working that I continue to use:
What does the object need to know?
How can it sense that information?
What should happen in response?
What mechanism can create that action?
How do the parts communicate?
The research began with electronics, but the larger lesson was about integration.
Responsive objects are not collections of sensors, motors and code. They are systems in which information becomes physical behaviour.
