Latest Post:

The Tire Scanner Project

Regular accurate tread depth measurement of tires is required for a vehicle to maintain a safe level of performance in various road conditions. The manual process of doing this involves using a mechanical tread depth gauge (or an improvised tool) to take the tread depth. While tread depths can be effectively taken this way, it is a process which can benefit from modern technology and automation. It is desirable for depths to be taken across the tire surface which when done traditionally means multiple manual measurements, each measurement carrying the possibility of user error.

An easy way to gauge the tread depth of a tire across its surface involves shining a line laser diode over the surface of a tire at an angle and then taking a photo of the tire surface with the laser line visible. The photo can then be filtered to only show the laser colour and as the angle of the laser is know then the tread depth can be worked out mathematically. An example of what such a red line might look like is below:

A tire is a particularly good object for such an approach as it is a dark not reflective surface.

At Tirelabs we are currently working on constructing our own devices based on this principle. This project is both done for field usage and to gain a better understanding about the measurement of tires. 

The steps intended to be taken are the construction of a traditional 3d scanner as used for generating 3d models from existing objects. These involve the angular laser described above and a turntable on which a small object can be placed. The same mechanism previously described can create a 3d model of the rotating object. This is due to the high amount of pre-existing information on the construction of such scanner and that such a thing gives us a baseline performance on which to test the process. 

After this initial research step is achieved we can begin construction of a handheld scanner to take tire treads and potentially look at other use cases.

Interesting Further Reading:

https://www.instructables.com/3D-Laser-Scanning-DIY/

https://www.researchgate.net/publication/321668948_Rapid_3D_Printing_for_your_Lab_How_to_make_a_DIY_low-cost_3D_Scanner


Photogrammetry of Tire Surfaces in Real World Conditions

Photogrammetry is the practice of using 2d images to create a 3d model of an object. If enough photos of an object from different angles are taken an attempt can be made by a computer to stitch them together to form a 3d scene. Some of the uses of this technology are hobbyists "scanning" small objects by taking photos of the object on a turntable. Another usage is taking aerial photographs and using them to create 3d renderings of buildings and environmental features.

Pontentially photogrammetry can be used to investigate tires and presents a potential method for gauging tread depth and diagnosing issues with a tire. To explore this possibility I began an initial investigation by using a Motorola G7s Plus phone to take photos of a rear tire installed on a Mazda CX-5. 30 photos were taken with the phone in a handheld manner at various angles of the tread pattern from the rear side of the vehicle. 

This led to the creation of a 3d object of the Tread that is represented in the photos below:

 

Another angle of the 3d model:

 

The inside of the tire:

 

Inside of the tire at an angle showing depth:

Clearly from the photos depth information has been captured. This proves that tread depth can be captured from photos taken in non ideal circumstances. Challenges remain in extracting the tread depth information and providing accurate results. This is a computationally expensive process currently and that presents another challenge to implementation.

Further experiments in generating point cluster clouds with less computational requirements could lead to conclusions that allow for consumer level implementation. There is also the possibility that stereophotogrammetry could lead to relatively inexpensive devices to capture depth information from objects.

The most important conclusion for the purposes of Tire Labs experiments is confirmation that depth information can be extracted from photographs of tire treads in a real world environment.

 


Tire Scanning

Tire Tread Depth Measurement White Paper

August 2020

 

This paper looks at the causes and the influences that support the growth in tire tread depth measurement devices and proposes answers and thoughts on the question.

“How would the Tire Industry be affected if Tire Tread Depth readings were ubiquitous?”

Our company has purchased Laser based Tread Reader technology and we are busy integrating the process with our software. We are collaborating with the local Automobile Association to understand the technology and its applications

I consider in the initial discussion the categories

  • Opportunistic
  • Economic
  • Safety
  • Performance
  • Insurance

These are arbitrary classifications.

 

Opportunistic

We expect that companies such as Auto Dealerships will use the technology in an opportunistic way.  Promoting tire replacement when the primary reason the vehicle is presented is for routine or mechanical service.

This varies from a user that understands they have a tire need and takes the vehicle to the Tire Shop.

We see other opportunistic uses, Vehicle Licensing Departments, Insurance crash repair reporting and Used car sales.

Entrepreneurial use that are opportunistic are scanners used in Automatic Car Wash Bays, Fuel stations and car parking. It is likely that subsequent scans come with advertising, special offers, not limited to tires. Wheel alignment or other mechanical service needs may be observed in irregular wear patterns in the tires, triggering offers for work to correct the problem.

 

Economic

Fleet Management and Leasing used to maximise tire life, restricting replacement to tires that barely comply with legal tread depth.

Scans for fleets are likely to be part of the service contract. The servicing agent offers Tire Scans at each service. The scans are recorded on the vehicles service history.  Accessed when the driver claims a need for tire replacement. Or pro-actively scheduled

Historic Records will highlight fraudulent tire replacements.

Driver analysis and comparison, review driving habits and vehicle use.

Historical records to help understand Mechanical problems, fuel use, cause of accidents etc.

 

Safety

Scans will be useful in managing risk in Public Transport.

Taxi’s, Ride Sharing could require that Vehicles are scanned periodically to ensure that Tires meet the legal requirements

 

Performance

Performance is a product of tire efficacy rather than legal requirement. It might be that tire scans are used to manage performance policy objectives

An imagined policy might require that Ambulances maintain their tires at no more than half worn during winter months where snow on the road is more likely

Scanners will be instrumental in ensuring this policy is applied

Another example will be Policies that are directed at Police vehicles that are expected to respond quickly requiring tread depths that are effective for that need.

 

Insurance

Insurance is likely to become a part of tire replacement ideology as new technologies such as, Driverless Cars, Share Cars, Electric Cars become popular.

Efficacy will become part of the discussion, regardless of the legal Tread Depth limits. 

A suitably advanced electric car with onboard computers will monitor the traction and reaction of all tires. The vehicle will access history of the driving conditions and the Drivers behaviour. There is likely a point where Tire replacement is considered necessary without reference to the legal tread depth.

Vehicles could be an intelligent agent affecting insurance. Information is a founding requirement for insurance, electric cars will provide the metrics for insurance companies to guide them on better policies.

Imagine an insurance policy that works in the following way

User Buys $500 of insurance for their fully electric car that is continually online, at the end of the month the used portion of the insurance gets billed and is topped up. The vehicle reports on the road conditions the driver’s habits and the vehicles own ability to mitigate the environment and avoid collision. The dashboard of the vehicle has a meter that shows the units of insurance that get used up.  Poor road conditions, erratic driving habits, poor quality tires use up the insurance allowance faster. 

If this type of insurance were applied to the new technologies of Ride Sharing or driverless cars, we would see the algorithm of Tire replacement become a metric of Efficacy not legal requirement (where Legal Requirement was an absolute reference in the algorithm).

We accept that this type of insurance of itself is most likely fanciful. However, it will be more relevant if car leasing is normalised. Many of the factors affecting the lease agreement are common to the insurance cost and would factor together.

 

Efficacy rather than Tread Depth

Tread depth is arbitrary requirement that does not deal specifically with the tires performance in given situations. A Tire may in some situations have legal tread but not be suited to the specific situation.

To understand Efficacy a system needs several data points. All data is related to historic data pool and will be considered learned understanding.

A good way to explore this better is to use an example

A Driverless Electric Taxi moderates its speed according to its ability to control the vehicle. If the road conditions are snow covered and the vehicle has learned that a certain standard of tire traction is ideal between maximising the speed and reducing the potential of error (accident).  The vehicle may access historic records and decide that Tire Traction is a problem. The vehicle may request Tire Change If the conclusion is that it will gain 15% added speed with new tires.  (Note the vehicle needs to access a historic record to decide the potential gain)

The efficacy algorithm may determine that there is more value from increased speed (more paying fares) compared to the added cost of replacing tires that are otherwise legal.

The efficacy metric is applied now using human intuition, in spite of the new technologies. The reason it is not prominent is most likely that we are not able to adequately value the contribution of tires in the performance of the vehicle.

A Tire professional is likely to recommend new tires to a young family member with comments like

“Let’s get you new tires, you are an in experienced driver and we are heading into winter”    

This is in effect the Efficacy judgement.  

Efficacy already influences tire manufacturers; Tire performance is factored in above durability in many situations.

 

Fleet Vehicles / Privately Owned

We can imply details on ownership of vehicles by sector, from the Government Bureau of Transport Statistics

https://www.bts.gov/content/motor-vehicle-fuel-consumption-and-travel-metric

 

 

There are 273 million motor vehicles registered by 2018

 

https://www.bts.gov/content/retail-sales-new-cars-sector

 

 

 

Retails Sales of New Cars is almost 50% in both

  • Consumer
  • Business / Government

Pre 1990 the number of cars owned by “Consumers” was higher than 60%  (1965 = 76.1%) . There is an erratic upward trend toward increased business ownership of cars.

Without Evidence, we expect that business vehicles do higher miles (Increase the nett mileage travelled by fleet vehicles), business vehicles are replaced more often (reducing the population of Business Vehicles registered, for business use). The statistics show the rate of purchase of new vehicles, and not their enduring use by sector. Overall, we expect 50% of all passenger vehicle miles travelled are for business needs.

The importance of understanding the use of Business use from Personal Use is the compliance responsibility and the attitude toward tire replacement.

Business use of tire Scanners help with asserting compliance, reducing fraud, and managing cost effective use of tires for fleet needs.  The expectation is that increasingly business managers will look to Tire Scanning to decide tire replacement.

 

On Board Tire Measuring

https://dl.acm.org/doi/pdf/10.1145/3386901.3389031

It is likely that the technology over the long term will include vehicle on board tread depth sensors. The link above, is for a document that discusses the use of

Millimetre Wave Radar

The technology looks to be a while off. In mass production we expect the technology to be relatively in expensive.

This will not be the only technology being researched.

Let us imagine a vehicle with online internet capabilities and suitable onboard computing power that uses a technology that understands a tires tread depth during the vehicle’s operation. The vehicles computer will assess the role the tire plays in the performance of the vehicle and will coordinate the tire replacement.

Using a central data set that the vehicle contributes to and draws from, the most suitable tire for efficacy and durability will be calculated. The replacement tires will be a product of a mathematical process without consideration of brand loyalty or human intuition.

The Vehicle and the central data will be the Intelligent agent in Tire Purchasing

 

Drive over Scanners   

There are different brands that are commercially available now.

Driver over scanners by definition are independent of the vehicle.

Pairing the scanned data with the vehicle is currently problematic. It is not expected that the vehicles onboard computers will access the data from a drive over scanner and is more likely that the data on the tires scanned and the vehicle identification will be sent independently to the user or the fleet manager, not the Vehicle.

The lack of cohesion with the data between vehicle and tread depth scanners, removes efficacy as a tire replacement process, other than to have an Arbitrary policy applied as we discussed in “Performance” above  

Combine this with the fact that

  • Scanned data needs to be interpreted.
  • Without an efficacy metric, Interpretation needs to be based upon starting tread and minimum legal compliance

We will expect some vague relationship to Efficacy in the interpretation of a tire scan.

 

Interpretation of a Scan

If we agree that a typical tire starts with 10/32nds and is compliant over 2/32nds of an inch, what would we say about a tire that scanned at 4/32nds of an inch.

I expect that the likely interpretation would be something of the order

‘You should consider changing this tire”

A Tire scan (in the current format)  is only a small portion of the tires entire circumferential tread surface.

What do we say of a tire that has a worn part of the tread that makes the tire fail a test for compliance but this part of the tread was not in fact scanned, and did not show on the scan itself?  The scanned part of the tire shows as compliant.  

Compliance is for the entire tread surface not just the scanned area.   

Interpretation in this situation cannot be absolute, it must only be used as a guide. The interpretation needs to take note of the guidance of the scan and not be used to assure the vehicle operator that the tires do in fact comply with their legal obligations.

I expect a lawyer’s point of view on the use of a Scanner would be, without other direction the scanned tire could be seen by the user as professional advice of compliance.

Interpretations of a Tire Scan needs to be clear and give good advice.

 

Overview

It is reasonable for the Tire Industry to focus on legal compliance as the means to decide the replacement of tires and for this matter Scanners have a role.

With the ability to recycle tires using Pyrolysis or other technologies we could expect the resistance to waste to diminish.

Efficacy will be a product of many factors, I expect the growth of onboard computers in vehicles and their connectivity to the internet will gradually cause a change in the consumption, production, and distribution of tires. If at the same time waste is mitigated by recycling, we could see a stronger move to Efficacy in Tire replacement.  

Efficacy will affect the distribution of tires. If tires are manufactured with performance in mind. I would expect more tires to be replaced increasing the need to manufacture, recycle and distribute tires.

Efficacy will offset the added tire costs with benefits such as  , faster route performances, safer travel (lower insurance costs)  and fuel efficiency (electric car range extension).

Scanners will need to be onboard or at the least the data interchange between a drive over scanner and the vehicles on board computers will need to advance.

I expect the use of scanners to be needed in approaching fleet business. I also have the expectation that fleet tire mileages are increasing. I think these two factors make a compelling argument that companies adopt the Tire Scanning Technologies and create a business plan for their use.

 

Disclaimer

This document must not be considered as a statement of truth or accepted wisdom.

They are my thoughts on the subject.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  


Symbolic Regression From Scratch in C#

The aim of this series is for an intermediate C# programmer to have built a useful symbolic regression algorithm that they can easily extend in whatever direction fits their needs. I believe the best way to gain understanding of any machine learning concept is by implementing that concept and that is what I seek to facilitate here.

I completed this using .net core 2.2 with C#, though the from scratch nature of this project means that using a different C# setup is unlikely to be an issue.

All the code for this project can be found at https://github.com/Benzidrine/SymbolicRegression/

Definition:

Symbolic regression is taking a dataset and have a machine formulate an equation that best matches the data.

An example dataset of x,y values of [0,1], [1,2], [2,3], [3,4] is easily solvable by a human as: y = x + 1.

However something like [0,0],[1,1],[2,0.14],[3,-0.98],[4,-0.27] presents a far more difficult challenge even though it is a simple equation: y = sin(x*1.5)

This is where a computer and genetic programming can help us produce equations from limited data sets. This can be useful in real world scenarios for determining patterns without human bias and in forecasting.

The Project:

I created a new .net console app for convenience in these early development stages. I generally start small projects by defining the models and that is the approach I’ve taken here. Three models are required for the project. A Geneset model that defines the types of genetic expression, a Gene model to contain the expression plus its strength and a chromosome to contain an array of genes.

Geneset:

The geneset for our purposes is going to be the set of mathematically operations available to the genetic algo.

public enum Geneset
{
    Add,
    AddX,
    Subtract,
    SubtractX,
    Multiply,
    MultiplyX,
    Sine,
    Cosine
}

Here we have the needed primitive mathematical expressions that combined can generate approximations to quite a few functions. This enum will neatly define the primitive that each gene will be able to contain. In later parts we will likely remove some of these and add others.

Gene:

A gene here is a single sample of one operation from the Geneset and a value which represents the strength at which that operation will be applied.

public class Gene
{
  public Gene(Geneset operation, double value)
  {
    Operation = operation;
    Value = value;
  }
  public Geneset Operation {get; set;}
  public double Value {get; set;}
}

Chromosome:

The chromosome is what will store a list of Genes and will contain a lot of methods related to its function. Here we are getting to the heart of the project. The list of genes contained in the chromosome is the mathematical equation that we are trying to to make best fit the data.

public class Chromosome
{
    List<Gene> genes {get; set;}
    //Generates a random parent of set length
    public void GenerateParent(int Length)
    {
        genes = new List<Gene>();
        for(int i = 0; i < Length; i++)
        {
            genes.Add(GenerateGene());
        }
    }

    public Gene GenerateGene()
    {
        Random rnd = new Random();
        //Get number of values defined in Gene Set
        int GenesetCount = Enum.GetNames(typeof(Geneset)).Length;
        //Random value between 0 - 2
        double geneValue = (rnd.NextDouble() * 2);
        //Get random sample from Geneset
        Geneset geneset = (Geneset)rnd.Next(0,GenesetCount);
        return new Gene(geneset,geneValue);
    }  
}

The chromosome GenerateParent method is called to generate a random list of genes using the GenerateGene method. In our symbolic regression program we will call this method to generate a random parent and then mutate it for better fitness. This is how the process can get started.

Mutating the chromosome will be very easy using the same GenerateGene method we used to generate the parent except applied to a single random entry in the Chromosome’s genes.

public void Mutate()
{
    Random rnd = new Random();
    int Index = rnd.Next(0,genes.Count);
    genes[Index] = GenerateGene();
}

Now we have a chromosome created we need to establish the fitness of the chromosome which where the results of its genetic expression will be compared to the dataset. This will involve a call to another class to compute the list of genes that we will get to later. The fitness in our project will be the amount of error with 0 being the least possible error. To find this we will find the difference between the Chromosome’s Y prediction for an X value and the known Y value.

public double GetFitness(List<Tuple<Single,Single>> LineValues)
{
    double Fitness = 0;
    foreach (var item in LineValues)
    {
        Fitness -= Math.Abs((item.Item2 - ComputationManager.Compute(genes,item.Item1)));
    }
    return Fitness;
}

We follow this with a few utility functions. A display function will print out the mathematical equation represented by the list of genes and the clone function will help us make copies of the chromosome that are not linked in memory.

public string Display ()
{
    string Result = "";
    //Prefix allows for brackets which correct the order of operations for the statement 
    string Prefix = "";
    foreach (Gene g in genes)
    {
        switch(g.Operation)
        {
            case Geneset.Add:
                Result += "+" + g.Value;
                break;
            case Geneset.AddX:
                Result += "+x";
                break;
            case Geneset.Subtract:
                Result += "-" + g.Value;
                break;
            case Geneset.SubtractX:
                Result += "-x";
                break;
            case Geneset.Multiply:
                Prefix += "(";
                Result += ")*" + g.Value;
                break;
            case Geneset.MultiplyX:
                Prefix += "(";
                Result += ")*x";
                break;
            case Geneset.Cosine:
                Result += "+cos((x * " + g.Value + "))";
                break;
            case Geneset.Sine:
                Result += "+sin((x * " + g.Value + "))";
                break;
            default:
                break;
        }
    }

    return Prefix + "0" + Result;
}

public Chromosome Clone()
{
    Chromosome chromosome = new Chromosome();
    chromosome.genes = new List<Gene>();
    foreach(Gene g in genes)
        chromosome.genes.Add(new Gene(g.Operation,g.Value));
    return chromosome;
}

Now we have all the object models defined we need only create a function to compute the outcome of the equation contained in the list of genes and a console interface that allows us to use it all to analyze data and generate the best fit equation. The first thing to create is the computation engine that will compute the operations contained in the geneset and apply them to a given value. Allowing us to test fitness and therefore mutate chromosomes to better fit a given data set.

Computation Manager:

public class ComputationManager
{
    public ComputationManager() {}

    public static double Compute(List<Gene> Genes, double x)
    {
        double y = 0;

        foreach(Gene g in Genes)
        {
            switch(g.Operation)
            {
                case Geneset.Add:
                    y += g.Value;
                    break;
                case Geneset.AddX:
                    y += x;
                    break;
                case Geneset.Subtract:
                    y -= g.Value;
                    break;
                case Geneset.SubtractX:
                    y -= x;
                    break;
                case Geneset.Multiply:
                    y *= g.Value;
                    break;
                case Geneset.MultiplyX:
                    y *= x;
                    break;
                case Geneset.Cosine:
                    y += Math.Cos((x * g.Value));
                    break;
                case Geneset.Sine:
                    y += Math.Sin((x * g.Value));
                    break;
                default:
                    break;
            }
        }

        return y;
    }
}