Our goal for this project was clear: we needed to deliver a working proof-of-concept (PoC) fast, but it also had to be built on a solid foundation that could support future growth.

‍

Choosing the right tools and strategy

The client already used Microsoft Azure for their operations. Which made the decision simple: we would build the solution within their existing environment. This approach kept things straightforward and made cost tracking easier.  

We drew on our experience with integrated machine learning platforms and recommended Databricks. This gave them a unified workspace where they could handle data, finetune models, manage training, and track everything using MLflow and Unity Catalog. This setup significantly sped up the development cycles, which is especially convenient when trying out proofs of concept.
‍

A collaborative approach to data

The deep domain knowledge and proactiveness of the client's team were major reasons for the project's success. For example, our first analysis showed that the raw images needed perspective correction before we could use them effectively. Their experts immediately took on this pre-processing task themselves. They also handled the critical job of labelling the image data, which was essential for training the AI model.  

This high level of client involvement meant that we could concentrate entirely on the AI system itself. The project moved forward much faster as a result. A truly streamlined way of working together!

Object detection over standard OCR

We ran some early tests, which quickly confirmed that standard OCR techniques wouldn't work well enough on these images. The low quality, the angled camera perspective, and the way digits transition on analogue meters (sometimes showing parts of two numbers at once) were too challenging. So, we decided on a different path: object detection using the well-established YOLO (You Only Look Once) model.

We specifically trained YOLO for the task of detecting the digits 0 through 9 within the meter images. This method turned out to be much better suited for several reasons:

• It focuses only on the target digits, ignoring other text on the meter face.
• It handles the limited number of classes (0-9) efficiently.
• It also shares the precise location (bounding box) and a confidence score. This allows the client's downstream logic to intelligently handle ambiguities, like partially visible digits or digits the model is less certain about.
  ‍

Iterative development and PoC pipeline

Training the model was (as always with AI and ML) an iterative cycle. We started with the labelled data and trained the initial models. The client then evaluated the performance by plotting the predicted readings in their dashboard and visually checked for any strange results or anomalies. They then supplied new labelled data, which we used to retrain the model. With each cycle, the model's accuracy steadily improved.

For the PoC, we set up a straightforward batch processing pipeline:

1. The client uploads new meter images into a dedicated Azure SQL table.

2. A scheduled Databricks job runs (daily at first) and retrieves the latest images from the database.

3. The job applies the trained YOLO model to these images in a batch inference process.

4. Finally, the raw detection results (including the digit, its bounding box coordinates, and the confidence score for every detection) are written back into a separate table in the Azure SQL Database.

The client then takes this raw output from the database and applies their own post-processing logic which assembles the final meter reading. By using the location and confidence data from our model, they can interpolate missing digits or handle uncertain detections based on their domain expertise.
‍

Building for the future

This first phase focused on proving the concept successfully for one specific meter type in a controlled setting. However, the architecture we chose and the collaborative way we worked together provide a strong foundation for what comes next.

We've already discussed future steps with the client. These include strategies for handling various other analogue meter types, perhaps by training specific models for each type or by fine-tuning a general model. We also talked about creating an onboarding process for new meters, as they prepare to scale its camera deployment potentially to thousands of units.