Case Study · Robotics · Animal Welfare
CANIS
A behaviour robot for my fearful dog that only ever rewards — built on the position that if a machine is going to interact with an anxious animal, welfare has to be an architectural constraint, not a setting.
Built · Working
The problem
My dog, Shifu, is fearful. Most consumer "training" devices attack that problem with aversives — spray, noise, static — which for a fearful dog doesn't fix behaviour, it deepens the fear. The behaviour-science approach that actually works is graded exposure with positive reinforcement: let the dog choose the right behaviour, reward it instantly, and never push past the level the dog can handle.
That protocol is very demanding for a human to run consistently. It is, however, exactly the kind of thing a machine can do with perfect patience.
Constraints
- Never punish. There is no aversive output anywhere in the system — the only actuator pointed at the dog dispenses treats.
- Never advance at low exposure levels. The exposure ladder is graded, and the state machine will not escalate while the dog is at a low exposure level. Escalation is earned, not scheduled.
- Fail safe around an anxious animal. A moving robot near a fearful dog must stop the moment perception degrades.
- Cheap, replaceable hardware split across three controllers, so any one part can be swapped or debugged in isolation.
The core design inversion: CANIS rewards Shifu for leaving a zone — reinforcing the dog's own choice to disengage — rather than punishing him for entering one. Same behavioural goal, opposite emotional experience for the dog.
System architecture
CANIS is deliberately distributed across three controllers, each doing the job it's best at:
- Raspberry Pi 5 — perception. Tracks position via ArUco marker vision and publishes where the dog is relative to the defined zones.
- ESP32 — behaviour logic. Runs the arousal state machine: hysteresis keeps the state from flapping at boundaries, and graded exposure levels gate what the system is allowed to do next. It never advances while exposure is low.
- Arduino — actuation. Drives the treat dispenser on command.
Safety is enforced by a ~1-second motion watchdog: if fresh vision data stops arriving, all motion halts within about a second. The robot is only ever allowed to move while perception is provably alive.
Perception
Raspberry Pi 5 · ArUco marker tracking
Behaviour logic
ESP32 arousal state machine · hysteresis · graded exposure levels
Actuation
Arduino treat dispenser
Fail-safe
~1 s motion watchdog — halt on stale vision
Principle
Reward for leaving a zone · no punishment path exists
Subject
Shifu (the dog)
What I built
- The ArUco vision pipeline on the Pi 5 and the zone logic on top of it.
- The ESP32 arousal state machine — states, hysteresis thresholds, and the graded exposure ladder.
- The motion-watchdog fail-safe and the inter-controller messaging that carries it.
- The Arduino treat-dispenser firmware and the dispenser mechanism itself (CAD below).
- The chassis integration — all three controllers on one moving platform.
Results
CANIS is built and working: the full loop — ArUco tracking → arousal state machine → treat dispense on leaving a zone — runs end to end on the real robot, with the watchdog verified to halt motion when the vision feed is interrupted.
Honest limitations
- Tuned for one dog. The exposure ladder and hysteresis thresholds are hand-tuned for Shifu; nothing here is validated across dogs.
- Marker-based vision. ArUco tracking means markers in the environment — robust and cheap, but not markerless perception.
- Behavioural outcomes are observational. I can show the system works as designed; I have not run a controlled study of Shifu's long-term behaviour change.
- Arousal is inferred from what the system can see, which is a proxy — not a physiological measurement.