If you’re building a computer vision or embedded AI system that needs to hold up in demanding real-world conditions, get in touch to start the conversation.
Executive Summary
Street lighting is one of the largest, most invisible line items in a council’s energy budget, because most of it burns at full brightness for hours when no one is around to use it. SmartLight set out to change that: a computer vision system that only brings a streetlight to full power when a person is actually approaching it.
Aegasis Labs partnered with a specialist streetlighting hardware company to deliver the AI side of the system for a UK government council — building the person-detection models, the data pipeline behind them, and the embedded optimization needed to run it all reliably on low-power hardware in the dark. Pilot testing validated the approach: 90%+ detection accuracy in difficult night-time conditions, and 30%+ energy savings against standard always-on lighting.
Built by Aegasis Labs in partnership with a specialist streetlighting hardware company, SmartLight uses on-device computer vision to detect when a person is genuinely near a streetlight and brings that light to full brightness only then — rather than burning full power from dusk until dawn regardless of whether anyone is there. The intelligence lives at the light itself. No cloud, no network dependency, no delay between someone stepping into range and the street lighting up around them.
Aegasis Labs owned the AI and embedded engineering side of the build: designing and training the computer vision models, engineering the training and data collection pipeline from the ground up, and optimizing everything to run reliably on low-power hardware mounted outdoors at each individual light.
About the Client
The client is a UK government council responsible for public street lighting across its jurisdiction, infrastructure that runs every night, everywhere, whether or not anyone is using it. Street lighting is one of those public services that only becomes visible when it fails, which is precisely why councils are cautious about changing how it works.
Aegasis Labs delivered the project in collaboration with a specialist streetlighting hardware company. That partnership split the work along clean lines: the hardware company brought deep expertise in the physical lighting estate — the fixtures, the electrical infrastructure, the realities of installing and maintaining equipment on a public street while Aegasis Labs built the computer vision and embedded intelligence layer that makes each light responsive.
Public infrastructure carries constraints that a lab project never has to reckon with. Hardware sits outdoors, unattended, through British winters, for years at a stretch. Power budgets are tight by definition — the entire premise of the project is using less energy, so the detection system itself can’t become a meaningful drain. And a system responsible for lighting a pavement at 2am cannot afford to miss the person walking down it. A false negative in this context isn’t a dropped frame in a benchmark; it’s someone left in the dark.
Every technical decision in this project was shaped by those realities.
The Challenge
The energy problem nobody had a good answer for
Standard street lighting is fundamentally wasteful by design. Lights run at full brightness through the entire night, consuming the same energy at 3am on an empty residential street as they do at 7pm on a busy high street. For a council operating thousands of lights across its estate, that waste compounds into a permanent, significant line on the energy bill — and into carbon output that public bodies face increasing pressure to reduce.
The obvious fixes trade one problem for another. Dimming lights across the board reduces energy use and reduces safety with it. Timer-based schedules assume the night follows a predictable pattern, which it doesn’t — shift workers, late trains, and early starts don’t check the timetable. Motion sensors using traditional PIR detection struggle to distinguish a person from a passing cat, a swaying branch, or a car, and tend toward either constant false triggers or missed detections.
Any approach worth deploying had to reduce energy consumption without reducing the light available to people actually using the street. That constraint ruled out every simple answer and pushed the problem squarely into computer vision territory — and straight into its hardest version.
Detecting people in near-darkness
The system had to reliably identify pedestrians and cyclists in exactly the conditions computer vision handles worst: very dark, low-visibility outdoor environments, at night, in unpredictable British weather. This was the core technical challenge of the project and the one that determined whether the entire concept was viable.
There’s a circular difficulty buried in the problem, too. The whole point of the system is that the light isn’t on yet — so detection has to work before the scene is illuminated. The model doesn’t get the benefit of the light it’s about to trigger.
Cyclists added another dimension. A cyclist approaches faster than a pedestrian and presents a different visual profile, which meant the model couldn’t simply be tuned for one type of moving person and left there.
A training data bottleneck before training could even begin
High-quality low-light footage suitable for training person-detection models isn’t readily available. Public computer vision datasets skew heavily toward well-lit, daytime imagery — which makes sense for most applications and makes them nearly useless for this one. Models trained predominantly on daylight data don’t transfer cleanly to a dark street; the visual features they learned to rely on largely aren’t there.
Without the right data, production-grade accuracy in night-time conditions simply wasn’t reachable. Data scarcity became a bottleneck that had to be solved before the modelling work could meaningfully progress — which is a different kind of problem than a modelling challenge, and one that a lot of AI projects underestimate.
Hardware that fights back
The models couldn’t run in the cloud. Detection had to happen on-device, at each individual streetlight, on low-power embedded hardware with limited processing headroom. Streaming video from thousands of lights to a central server would introduce network dependency, latency, bandwidth cost, and a privacy surface no council would want to take on. Local inference was the only sensible architecture.
But local inference on embedded hardware means working inside a hard ceiling. Model accuracy and hardware efficiency pull in opposite directions — bigger models generally detect better and run slower, and there’s no headroom to simply throw more compute at the problem. Both constraints had to be satisfied simultaneously, in an outdoor unattended setting where nobody is standing by to restart a process that’s fallen over.
The Solution
Purpose-Built Computer Vision, Engineered for the Dark and for the Edge
Aegasis Labs approached this as two connected problems: get the model right, then get it to run where it actually needed to run.
Computer vision model development
We designed and trained person-detection models built specifically to identify pedestrians and cyclists approaching a streetlight.
Rather than adapting a general-purpose detector and hoping it held up after dark, the models were engineered from the outset for low-visibility outdoor environments — the condition that defined the entire problem rather than an edge case to patch later. That framing shaped the architecture choices, the training approach, and the evaluation criteria throughout. A model that performs beautifully in daylight and degrades at night would have been a failure regardless of its headline accuracy figure.
Development ran iteratively: tune, evaluate against real night-time footage, identify where detection was breaking down, adjust, repeat. Through that cycle, the team reached 90%+ detection accuracy in difficult, low-light night-time conditions — the threshold that made the system trustworthy enough to control real public lighting on real streets.
Data collection and training pipeline
Because the low-light data simply didn’t exist at the quality required, we built it.
Aegasis Labs established a structured process for collecting and labeling real-world night-time footage to train and validate the detection models. This wasn’t a side task — it was foundational infrastructure for the project, directly addressing the data scarcity that would otherwise have capped accuracy well below production grade.
The pipeline paid off twice over. First, it gave the models training data drawn from the actual conditions they’d operate in, rather than a proxy. Second, it gave the team a reliable way to validate — every architectural change could be measured against footage representative of real deployment, so improvements were genuine rather than benchmark artifacts.
That validation loop is what allowed training data and model architecture to be iterated together, balancing detection accuracy against the hard constraints of the embedded hardware. Each round fed the next: better data exposed where the model was weak, architectural changes were tested against that data, and the accuracy ceiling moved up.
Embedded systems engineering
Once the model performed well in testing, it still had to run on the hardware installed at each streetlight. The team deployed and optimized the models specifically for Raspberry Pi, tuning inference performance to operate reliably within the power and processing limits of embedded chips running unattended, outdoors, night after night. The final models were deployed and optimized to run on Raspberry Pi hardware installed at each streetlight.
This was as much an engineering problem as an AI one. Inference performance had to be tuned to run reliably within the power and processing limits of embedded chips, in an outdoor unattended setting where there’s no opportunity to intervene when something slows down or stops. A model that runs correctly for six hours and then degrades is not deployable at this scale — the failure mode would be invisible until someone noticed a dark street.
Optimization work focused on making the models efficient enough to sustain real-time inference within that envelope without surrendering the accuracy earned during training. The outcome is a system where detection happens locally, at the light, in real time: no cloud round-trip, no network dependency, no perceptible gap between someone stepping into range and the light responding.
What Was Built
- Person-detection models: CNN-based computer vision models trained specifically to detect pedestrians and cyclists in low-light, outdoor, night-time conditions.
- Low-light data pipeline: A structured process for collecting and labeling real-world night-time footage, purpose-built to address the shortage of usable training data for this scenario.
- Embedded inference optimization: Models tuned and deployed to run efficiently on Raspberry Pi hardware, balancing detection accuracy against the power and processing constraints of on-site embedded systems.
- Pilot deployment: A live pilot program with a UK government council, testing the full system — detection, hardware, and energy behavior — under real-world operating conditions.
Technologies Used
- Python for model development
- CNN-based object and person detection architectures
- Raspberry Pi for embedded deployment
Implementation
The project moved from model development through to a live deployment with the council.
Data collection and labeling ran first and continued throughout, feeding each round of model iteration rather than being treated as a one-off preparatory phase. As detection accuracy climbed toward the target threshold, focus shifted progressively toward optimization — compressing and tuning the models until they ran within the Raspberry Pi’s processing and power envelope without giving back the accuracy earned in training.
Hardware integration ran in coordination with the specialist streetlighting partner, whose infrastructure the detection system had to work within. The division of expertise mattered here: the lighting company understood the physical estate and installation realities, Aegasis Labs understood what the models needed to perform, and the integration had to satisfy both.
From there, the system went into a live pilot across the council’s streetlighting estate. The pilot was the real test — not benchmark conditions, but actual streets, actual weather, actual pedestrians and cyclists moving through the dark at hours when nobody is watching. Pilot deployment measured both sides of the equation: whether detection held up in the field, and what the energy consumption actually looked like against standard always-on lighting.
The Results
30%+ energy savings. During initial pilot testing, SmartLight delivered more than 30% energy savings compared with standard always-on street lighting — achieved without reducing the light available to anyone actually using the street. That’s the number that matters to a council balancing an energy budget against a carbon commitment, and it was measured in live deployment rather than modelled.
90%+ detection accuracy in low light. The person-detection models reached over 90% accuracy in difficult night-time, low-visibility conditions. This is the metric that made the energy saving safe to pursue — high accuracy is what allows lights to stay dimmed with confidence, because the system can be trusted to notice when someone arrives.
Reliable on-device inference. Detection runs locally on Raspberry Pi hardware at each light, within the power and processing constraints of embedded chips, in unattended outdoor conditions. No cloud dependency, no network bottleneck, no central point of failure across the estate.
A working low-light data pipeline. The structured collection and labeling process built for this project solved a bottleneck that blocks a lot of low-light vision work before it starts — and remains an asset for continued model improvement.
A validated path to wider rollout. The pilot did what a pilot is meant to do: proved the concept holds up outside a controlled environment, giving the council an evidence base — real savings, real accuracy, real deployment — to justify expanding across a wider estate.
Build Your AI Platform with Aegasis Labs
SmartLight worked because the hard parts were treated as the actual project rather than as details to solve later. The team built a low-light training dataset from scratch instead of assuming a general-purpose model would generalize into darkness. Optimization for embedded hardware started early rather than becoming a scramble at the end to squeeze a workstation-sized model onto a Raspberry Pi. And accuracy targets were set by what the deployment context demanded — public safety on a live street — not by what looked good in a report.
That’s the pattern across Aegasis Labs engagements: AI built for the environment it has to survive in, not the one it was benchmarked in. Working alongside a specialist hardware partner, our team delivered the engineering layer that turned a good idea about public energy efficiency into a deployed system with measurable savings behind it.