Latest / The Edge Computing Podcast with Fexingo: Local Compute, CDNs, and Distributed Infrastructure / How Edge Computing Is Enabling Real-Time AI Inference on Construction Sites
Transcript
- Lucas: If you walk onto a large construction site today, you'll see something that wasn't there five years ago: a handful of small, ruggedized boxes bolted to scaffolding or tucked inside equipment trailers, each running AI models locally, right where the work is happening. Luna: You mean edge devices doing inference on-site, not sending video up to the cloud and waiting for a response. Lucas: Exactly. And one of the most interesting deployments I've come across is at Mortenson, the general contractor behind some of the tallest buildings in the US. On a recent 40-story tower project in Chicago, they deployed about 15 edge nodes running NVIDIA Jetson modules — each one processing feeds from multiple construction cameras in real time. Luna: What kind of models are they running locally? Safety detection, I'd guess, given the focus on OSHA compliance. Lucas: That's a big part of it. The primary model detects whether workers are wearing hard hats, high-vis vests, and harnesses when working above a certain height. But they've also trained models to track the location of heavy equipment — cranes, forklifts, aerial lifts — and to flag when someone enters a restricted zone. The latency requirement is critical: if a worker steps into a danger area, the system needs to trigger an alert within a second or two, not the five-plus seconds you'd get sending that frame to a cloud server and back. Luna: So the edge node is doing inference locally, then maybe sending a lightweight alert or a metadata summary to a central dashboard. Lucas: Right. The raw video never leaves the device. Mortenson's system captures 1080p feeds at 15 frames per second from each camera, runs them through a YOLOv8 model — that's 'You Only Look Once,' the real-time object detection architecture — and then only pushes a JSON payload with bounding boxes and timestamps to a web dashboard. Over a 24-month build cycle, that saved them an estimated 12 terabytes of video upload bandwidth. More importantly, it meant the model kept running even when the site's cellular connection dropped, which happened regularly. Luna: I want to dig into the hardware side. You mentioned NVIDIA Jetson — which specific module? And how rugged do these enclosures need to be on a construction site? Lucas: Mortenson used the Jetson Xavier NX for most nodes, which gives about 21 TOPS — that's trillions of operations per second — at around 15 watts. That's enough to run multiple models simultaneously. The enclosures are IP65-rated industrial cases with active cooling fans, because on a steel and concrete tower in July, internal temperatures can hit 50 degrees Celsius. Each box has a cellular modem for fallback, but the primary link is a site-wide Wi-Fi 6 mesh — Mortenson strung Ethernet cables up the elevator shaft and put access points on every fifth floor. Luna: Fifteen nodes for a 40-story tower — that's roughly one node per three floors. How did they decide placement? Lucas: They focused on high-activity zones: the loading dock, the main hoist area, the current top deck where concrete pours happen, and the central stairwells. Each node covers about three to four cameras, so roughly 50 cameras total. The interesting design choice is that the models are not all identical. The nodes at the top deck run a heavier model that also detects structural elements — rebar placement, formwork alignment — because the project engineers wanted to compare as-built progress against the BIM model. Luna: BIM — building information modeling. So they're doing real-time quality assurance on-site, not just safety. Lucas: Exactly. The BIM comparison model is a lightweight variant of a neural network trained on synthetic data from the project's 3D model. It runs at about 8 frames per second, and when it detects a discrepancy — say, a rebar cage that's 10 centimeters off from the plan — it flags the foreman's tablet within seconds. Mortenson told me that in the first six months, that model caught 14 alignment errors that would have required rework later. Each rework event costs an average of $8,000 to $15,000 in labor and materials, so they estimated a direct savings of over $150,000 from that single use case. Luna: Let's talk about the network challenges. You mentioned spotty cellular — what does edge compute do when the connection drops entirely? Lucas: The system degrades gracefully. Each node stores up to 48 hours of inference results locally on a small SSD. When the connection returns, it syncs the metadata in a compressed batch. The models keep running, alerts still trigger on-site through a local buzzer system and LED panels. The dashboard just goes stale until the link is restored. For Mortenson, that meant zero downtime for safety monitoring, even during a two-day outage when a backhoe cut a fiber line. Luna: That's a compelling argument for edge inference over cloud-only: resilience during infrastructure failures. But what about cost? Those Jetson modules with enclosures and cameras — what's the per-node price? Lucas: A fully deployed node runs about $3,500 to $4,500, all in — including the Jetson module, the industrial case, cooling, power supply, and the PoE switch for three to four cameras. For 15 nodes, that's roughly $60,000 in hardware. Compare that to the cloud alternative: streaming 50 cameras at 15 fps to a cloud inference service would cost around $1,200 per month in compute and bandwidth, or $28,800 over two years. But you'd also need persistent high-bandwidth connectivity, which on a construction site often requires a dedicated fiber line — that's $500 to $1,000 per month. So the edge solution pays for itself in about 18 months, and you own the hardware. Luna: So the total cost of ownership favors edge for projects longer than a year or so. But what about smaller contractors — mid-size firms doing a 10-story apartment building? Can they justify that upfront? Lucas: That's the open question. Mortenson is a top-20 US contractor with the scale to pilot this. But I've seen a few startups offering edge inference as a service, where you rent the nodes by the month — roughly $800 per node per month, including maintenance. For a 4-node system on a 12-month project, that's $38,400, which is much more palatable than a $60,000 upfront buy. The models are pre-trained for common safety and progress monitoring tasks. I think that's how the technology trickles down to smaller firms. Luna: Are there any downsides to edge inference on-site that you've heard about in practice? Lucas: The biggest complaint from Mortenson's IT team was model update logistics. When they wanted to retrain a model — say, to recognize a new type of crane or a different hard hat color — they had to physically visit each node to swap out the model file. They've since set up a secure remote update mechanism using signed containers, but it was a painful first few months. Also, the heat dissipation in summer means the fans are loud — workers on the top deck complained about noise near the edge box. They had to relocate one node because it was right next to a welding station. Luna: Hardware constraints: thermal, acoustic, physical location. Edge computing in construction is not a server rack in a cool data center. Lucas: Not at all. But as chip efficiency improves — the newer Jetson Orin runs at similar TOPS with lower power — and as model compression techniques like quantization and pruning become standard, these devices will get smaller, cooler, and quieter. I think within three years, we'll see edge inference on construction sites as a standard line item in project budgets, like security cameras or portable toilets. Luna: You mentioned model compression — is that something Mortenson used on their YOLOv8 model? Lucas: They did. They quantized the model from FP32 to INT8, which reduced the model size from about 240 megabytes to 60 megabytes, and inference speed improved from 35 milliseconds per frame to 12 milliseconds per frame — with only a 1.2 percent drop in mean average precision. That's a trade-off almost every edge deployment makes: you sacrifice a tiny bit of accuracy for major gains in speed and power efficiency. Luna: That precision drop is negligible for safety alerts — you'd rather have a false positive than miss a real hazard. So the math works. Lucas: Exactly. And in the construction context, a false positive just means a supervisor gets a buzzer alert that turns out to be a worker bending over to tie his boot. Annoying, but not dangerous. The false negative — missing a worker without a harness — is the real risk. The INT8 model actually performed better on recall for hard hat detection than the FP32 version, probably because the quantization acted as a regularizer. Luna: I want to loop back to the BIM comparison model. That's a more advanced use case — how are they training it on synthetic data? Lucas: They took the project's Revit model — that's the BIM authoring tool — and rendered thousands of synthetic images from different camera angles, with varying lighting and occlusion conditions. Those images were automatically annotated with ground-truth bounding boxes for structural elements like columns, beams, and rebar mats. Then they fine-tuned a pretrained ResNet-50 model on that synthetic dataset. The key insight is that they never needed to label a single real-world image by hand. The synthetic data was sufficient to achieve 87 percent mean average precision on real site photos — good enough for early detection of major alignment errors. Luna: So the edge node is effectively comparing reality to the digital twin in real time. That's a powerful feedback loop for construction quality. Lucas: It is. And it hints at a future where every major construction project has a digital twin that updates continuously from edge sensor data. Not just cameras — but LIDAR, thermal sensors, even acoustic sensors for detecting cracks in concrete. Mortenson's next pilot includes a microphone array on one node to detect the sound signature of a drill hitting a rebar — which indicates a misplaced penetration — and trigger an alert. All processed locally. Luna: Multi-modal edge inference. That's going to require more compute per node — maybe the Orin modules with higher TOPS. Lucas: Or a dedicated DSP for audio. But the trajectory is clear: edge compute is becoming the default for latency-sensitive, bandwidth-constrained environments. And construction is one of the most hostile environments for technology — dust, vibration, temperature swings, power fluctuations. If it works there, it can work almost anywhere. Luna: That's a good note to end on. But before we wrap — if this kind of real-world edge deployment story is useful to you, and you want to keep hearing them without ads, listener support is what makes that possible. You can find us at buy me a coffee dot com slash fexingo. Just a simple way to help us stay independent. Lucas: Yeah, we keep the podcast ad-free and focused on specific cases like this one because listeners tell us they want depth, not commercials. So if it's added value, that link is there. And to close the loop on Mortenson: they're now expanding the system to three other projects, including a hospital renovation in Denver and a data center campus in Virginia. The hospital project is particularly interesting because they're adding a model to detect when a worker's heart rate or skin temperature suggests heat stress — using thermal cameras. That's a use case that's almost impossible to do reliably with cloud-only inference. Luna: Heat stress detection on the edge — that could save lives. Great example of how local inference enables applications that just aren't practical with cloud round-trips. Lucas: Exactly. And that's the thread we'll keep following: where edge compute unlocks something that wasn't feasible before. Thanks for listening.