-
-
CrackPulse live on AWS EC2 Graviton: crack width in mm, vibration in Hz
-
Crack measured with U-Net: 1.6 mm typical width, BRE Category 2 (Slight), with an AI view vs photo slider
-
Inspection agent draft report with step-by-step log. Always marked for review by a qualified engineer
-
Vibration from video: ArUco marker tracking + FFT measured 3.0 Hz and 2.03 mm on a known test signal
Inspiration
What it does
How we built it
Inspiration
Cracks and vibration are early warning signs for bridges and buildings, but checking them is still mostly manual: an inspector with a crack gauge, a notebook and specialised equipment. I wanted to see how far a normal phone camera, a printed marker and OpenCV 5 could go in turning that into real numbers: crack width in millimetres and vibration in hertz.
What it does
CrackPulse is a web app (live on AWS) with two tools and an inspection agent:
- Crack inspection: place a printed ArUco marker next to a crack and take a photo. OpenCV 5 detects the marker, corrects perspective and computes the mm-per-pixel scale. A U-Net (MobileNetV2 encoder) segments the crack, and the app reports median width, max width, length and a BRE damage category (0–5). A classical OpenCV method is also available for comparison. A before/after slider shows what the model sees.
- Vibration measurement: fix the marker on a structure and film it. OpenCV tracks the marker with sub-pixel corner refinement in every frame, converts the motion to millimetres, and an FFT gives the dominant frequency (Hz) and amplitude (mm).
- Inspection agent: decides which tools to run, reuses earlier measurements, handles failures (for example "marker not found, retake the photo"), logs every step (tool, input, output, time), and writes a draft report. Every report is labelled "Draft, needs review by a qualified engineer". The agent never declares a structure safe.
How I built it
- OpenCV 5.0 for ArUco detection (DICT_4X4_50), homography rectification, sub-pixel corner tracking, morphology and skeletonisation for length, distance transform and edge profiles for width, and
cv2.dnnto run the ONNX model. - U-Net with a MobileNetV2 encoder, trained in Google Colab on the DeepCrack dataset and exported to ONNX, running on CPU with tiled inference.
- Flask web app with a mobile-friendly UI, served by gunicorn.
- Agent in Python using the Amazon Bedrock Converse API with tool use, plus an offline rule-based fallback.
- AWS: Docker container on EC2 t4g.small (Graviton, Arm64), Amazon Linux 2023, Sydney region.
Results
- Crack segmentation (DeepCrack test set): U-Net F1 0.856 vs classical method F1 0.334.
- Real printed calibration sheet (lines of 0.3, 0.5, 1.0 and 2.0 mm, full-resolution phone photo): every measured width was within about 0.06 mm of the true width. This was tested on one full-resolution photo so far.
- Compression matters: the same sheet sent through WhatsApp (about 2.4 px/mm instead of 12.3 px/mm) gave errors up to +102%, and one photo failed completely. CrackPulse needs the original image.
- Vibration (synthetic video with known motion, 3.0 Hz / 2.0 mm): measured 3.0 Hz / 2.026 mm, with the marker found in 300 of 300 frames.
Challenges I ran into
- The U-Net was trained on real concrete, so it misses clean computer-drawn and printed lines, while the classical method handles those well. On real textured surfaces it is the other way round.
- Early width measurements were stuck in 0.2 mm steps. I switched to a sub-pixel edge-profile method, which brought thin-line errors from about +0.1 mm to about ±0.05 mm.
- On floor tiles, the straight tile joints are also detected as cracks, so length can be over-estimated.
- My new AWS account had a Bedrock quota of 0 for Claude Haiku 4.5, so the live demo uses the agent's offline rule-based fallback. The Bedrock integration is built and the fallback path is visible in the agent log.
What I learned
Measurement is only as good as its scale and its input: a printed marker, a straight-on photo and an uncompressed image matter as much as the model. I also learned to report results honestly, including where the system fails.
What's next
- Test on more real cracks and compare with a crack-width gauge.
- Ignore tile joints and let the user select the crack region.
- Speed up analysis on EC2 by keeping the model loaded in memory.
- Enable the Bedrock-powered report once the quota is approved.
Built with help from Claude (Anthropic) as a coding assistant.
Log in or sign up for Devpost to join the conversation.