Michele Damian

Michele Damian

Security Agent

Cameras that remember who they’ve seen.

A security camera system that spots people and vehicles on a tiny edge computer, recognizes them across cameras and across days, and answers questions about them in plain English.

What the demo shows Camera 1 left, camera 2 right, chat in the middle

  1. A man crosses camera 2, then camera 1. Each camera picks him up and tracks him.
  2. In chat: “have you seen anybody in the last couple of minutes?” The answer describes the two people seen, with what they wore, where and when.
  3. An alert is set for one of them: “tell me when the man with a black cap comes back.”
  4. He comes back on camera 1 and the alert fires. He then crosses camera 2, and it fires again from there.

Results

  • 94%

    Recall re-identifying people across cameras that don’t overlap, with no false matches.

  • 95%

    Recall re-identifying vehicles across days, with no false matches in 2,300 pairs.

  • < 10 s

    From a person first appearing on camera to the alert arriving in chat.

  • 2 fps

    Detection and tracking on a Raspberry Pi Zero 2. 512 MB of memory, no GPU, no fan.

  • 5%

    of frames ever reach the cloud. Only genuine movement gets sent.

  • Capped

    AI cost per event. A fixed frame budget, whether someone walks past or lingers.

Three parts, one system

  1. On the camera

    Finds people and vehicles, follows each one from frame to frame, and keeps only the moments where something really moves.

  2. In the cloud

    A vision-language model describes what happened. Appearance signatures link the same person or vehicle across cameras and days, into one searchable history.

  3. In your chat

    Ask questions and set alerts in plain English. Alerts arrive the moment they fire.

It only pays for AI when something happens.

Sending every frame from every camera to an AI model in the cloud would cost a fortune. So the camera decides first: only the moments when something is really moving go up, about 5% of all frames.

Changed pixels alone aren’t enough to go on. A parked car, a passing shadow or headlights sweeping across the yard all change the picture while nothing happens. The camera tracks each object and estimates how fast it actually moves through the scene, from a single uncalibrated lens.

A parked car marked as stationary and ignored, next to a walking person marked as moving Car · stationary3 Person · moving4
The parked car is tracked but never sent. The walking person is.

It knows who it has seen before.

Every person and vehicle gets an appearance signature. When the same one walks into another camera’s view, or comes back next week, the system connects the sightings.

Recurring visitors surface on their own, without anyone labeling them.

The same person seen by camera 1 and, one minute later, by camera 2, keeping the same identity Camera 1 Person7 Camera 2 Person7 Same person, one minute later

It recognizes the same car at every gate.

A family house on a corner, with a camera on each way in: the driveway, the side gate, the back gate. Each one watches the house’s own ground, and none of their views overlap.

When the same car turns up at the back gate, then the side gate, then the driveway, its appearance signature ties the sightings together. You get one car and where it went, not three unrelated alerts.

Map of a corner house bordered by three streets, with a neighbour's house on the fourth side. Three numbered cameras on the house watch the driveway, the side gate and the back gate; their views don't overlap and stop at the street. A car drives past the back gate, the side gate and the driveway, and each camera picks it up in turn as car ID 12. Driveway Back gate Side gate Maple St Cedar St Birch Ave 1 2 3 Car12 20 m
Solid where a camera sees the car, dashed where none does. Same car, ID:12, at every gate.

Ask it what happened.

No more scrolling through hours of video. Ask in chat, in your own words, and get the answer in plain English. Behind it, the AI writes its own search of the event history, checks the results and fixes the search if needed. Searches are read-only, so a question can never change the data.

Alerts work the same way: describe what you want to know about, and every new event is checked against it.

Built with

  • Python
  • OpenCV
  • LiteRT
  • Raspberry Pi
  • Gemini
  • FastAPI
  • Google Cloud Run
  • PostgreSQL + pgvector
  • Discord

Tennis Robot Vision

It knows where the ball will bounce, before it does.

One camera and a small edge computer follow a tennis ball at 50 frames a second, rebuild its flight in 3D, predict where it will bounce, and place the bounce mark with an average error of 5 inches.

What the demo shows Half speed

  1. A shot comes over the net, and the ball is found in the first frames it appears in (yellow ring).
  2. The filtered track places it in 3D: the blue marker is the spot on the court right under the ball, the line its height.
  3. While the ball is still in the air, the predicted bounce appears (orange) and firms up with every frame.
  4. The panel in the corner plots the same track live, from above and from the side.

Results

  • 5 in

    Average error in where the ball bounced, estimated from one camera once it has landed.

  • 50 fps

    Ball detection on full 1080p frames, on an NVIDIA Jetson Nano. The rest of the pipeline runs only as fast as it needs to.

  • 20×

    Faster than YOLOv5 at the same full 1080p resolution, on the same device.

  • 200 ms

    Before the ball lands, on average. The bounce is called while the ball is still in the air.

  • 2 s

    From switching on to calibrated and ready. The procedure it replaced was done by hand.

  • 90 ft

    Detection range: all the way to the far baseline, where the ball is 2–3 pixels wide. YOLOv5 loses it beyond about 40 ft.

First, it calibrates itself.

Put the camera anywhere behind the baseline and, in about two seconds, it works out on its own exactly where it is, which way it points and how its lens bends the image. No calibration checkerboard, no measuring, nobody on court.

The court is the calibration target. A detector finds where the lines meet, the known geometry of a regulation court pins down each corner, even where a detection is weak or missing, and the camera’s position and lens distortion are solved from them.

The court seen from behind the near baseline, faded: white glows where the court detector found the lines meeting, each with a green dot where the fitted court geometry places that corner
White: corners the detector found. Green: where the court’s geometry puts them.

It finds a ball a few pixels wide.

At the far baseline a tennis ball is two or three pixels wide, and general-purpose detectors lose it. Shrinking the frame to suit them would erase it altogether.

A detector built for this one job works on the full 1080p frame and finds the ball anywhere on the court, from the net to the far baseline, 20 times faster than YOLOv5.

A court seen from behind the near baseline; a ball in flight just in front of the net is detected, and the real frame around it is shown magnified: the ball is about 8 pixels across ball A few pixels across
A real frame, just in front of the net: the ball is about 8 pixels across. At the far baseline it’s 2 or 3.

One camera. The whole court in 3D.

How far away the ball is comes from how big it looks. Where the player stands comes from mapping the image onto the court itself. Both are solved exactly, lens distortion included, so the flight path can be carried forward to the bounce.

Because the camera has calibrated itself against the court, every one of those measurements is in real court coordinates, ready to compare with the lines.

A ball's observed flight over the court, continued as a dashed prediction to its bounce point predicted bounce
Solid: where the ball has been. Dashed: where it will land.

It knows which ball is in play.

A practice court is never down to one ball. Some roll back after bouncing off the fence, some drift in from the next court. A detector finds every one of them, and on its own it can’t tell which one matters.

Each ball is tracked in 3D, with its position and its velocity. A ball that stays close to the ground is rolling, and is set aside. The ball in play is the one in the air.

Three balls on a court: one in the air, marked in play, with a line down to the court showing its height; two rolling along the ground, marked rolling rolling rolling in play height
Low and rolling: set aside. In the air: the ball in play.

Built with

  • Python
  • OpenCV
  • ONNX
  • NVIDIA Jetson Nano
  • Redis
  • AWS SageMaker Ground Truth
  • Mathematica