Tag: Analysis

Troglodyte: Driverless vehicles 2

“Effectively they attempt to patent the exact thing every good driver does.”

The purpose of Project Troglodyte is to hunt for bad patents and to show what went wrong. For more information, see the  web page.

DIAGNOSIS AND REPAIR FOR AUTONOMOUS VEHICLES


This patent is analyzed as part of a series of Google driverless car patents and applications. It is an emerging technology area which, I feel, will have a significant impact in 7-20 year time frame, perhaps even earlier. Existing Intellectual Property will make a difference on how the field develops.



Figure 1.


TIER 1: SUMMARY

A system where sensor information is used to determine wear or damage to parts of the vehicle, this information is then combined with information from environmental sensors and with map data to alter behaviour of the vehicle. For example: if the brakes are worn the system would use smaller deceleration than when the brakes are new. This is done to extend the life of the brakes, presumably until they can be overhauled. While the claims don’t seem to include it, the description also introduces a possibility for the vehicle to automatically seek a repair facility.

If this application is granted as is, it would likely cover some fundamental aspects of automated vehicles. It would cover a situation where external sensors indicate water on the road and the vehicle is able to sense significant tire wear and then decelerates to avoid hydroplaning. The current application doesn’t even attempt to explain how any of this is done; it is a description of a system that decides between different actions based on sensor and other inputs. Effectively they attempt to patent the exact thing every good driver does.

It should be noted that while the claims give an impression that this is about cars, it can be considered to cover other types of vehicles such as airplanes. In fact in the description  trucks, motorcycles, busses, boats, airplanes, helicopters, lawnmowers, recreational vehicles, amusement park vehicles, trams, golf carts, trains and trolleys are mentioned as examples of vehicles.

Looking at the news, it seems driverless car development is all about sensor fusion. Adequate sensor technologies are available, but putting together a system that makes sense of all the information takes a lot of work. Protecting solutions to problems that are encountered during development is standard practice. If granted this would in a fairly broad manner give Google a handle over an important optimization aspect of driverless vehicles.

TIER 2: AVOIDING LICENSING

Using a FEM model incorporating current sensor information to predict the response of the vehicle to current conditions could be used to change the behaviour without resorting to selecting from a list of possible actions. It is difficult to say if this differs enough from the language of the claims to be outside the scope of this application, but it could be useful in any case.

The obvious bypass route is to not use information about damage or wear to components internal to the vehicle. This however could restrict how aggressively the computer could use the vehicle as it would in some cases need to make a worst case assumption about the state of vehicle systems.

TIER 3: TECHNICAL ANALYSIS

The inventive step seems to be missing so discussion of novelty is a bit academic, but looking at novelty of the different parts can show that their combination is fairly obvious. Using sensors to monitor the internal wear and damage is a known technology. By way of example: a Yamaha two stroke outboard motor I used at least a decade ago had an internal oil tank. In case the motor was out of oil it reduced the available power to avoid engine damage. I remember this as it happened to me while I was crossing a shipping lane. It was quite exciting for a while, as there was a largish ferry approaching a couple of kilometers away and I judged that if I failed in filling the tank I might not have enough time to get clear. As another example: automobile engine management systems may change to a different throttle response and ignition timing in case they lose some sensors feeding information regarding the state of the engine.

It is also common to have an indicator in the car that warns when the outside temperature is close to freezing. Several current models also offer systems that read speed limit signs with a camera and give this information to the driver. Information about automated speed traps can be downloaded to navigation devices.

Fusing all this information provided by these prior technologies is clearly necessary in an autonomous vehicle. It might be an invention if a novel way of doing this was shown, but is not enough to tell that there is a problem in need of a solution. To go back to my claim that this is what drivers do all the time; it might be an invention to show how to do, with a computer, what happens inside the head of the driver. This is because the prior knowledge on that is pretty much missing.

The description and figures are easy to follow, apart of some patentese which needs a couple of passes before being understood. Not much new is offered so the usefulness of the description to society is low. There doesn’t appear to be a step change from prior technology or knowledge so the invention is missing.

The claims are pretty straight forward and they clearly are derived from the description. Some elements seem to be missing though, like the idea where the vehicle checks in to a maintenance facility when it detects something in need of fixing. But this is likely well covered in sci-fi so it would not be new.

Troglodyte: Driverless vehicles 1

“This is solid engineering but I didn’t get the “hey this is clever” reaction which is a sort of indicator for inventiveness.”

The purpose of Project Troglodyte is to hunt for bad patents and to show what went wrong. For more information, see the  web page.

 

TRAFFIC SIGNAL MAPPING AND DETECTION

I have been interested in driverless vehicles for years and I like to read patents, so why not combine the two and share my thoughts. This is a short analysis of a Google US patent application, you can find the original here.



Figure 1.

 

TIER 1: SUMMARY

Contents in one sentence: mapping of traffic lights to enable real time status detection of those lights by vehicles. The description is not limited to automated vehicles, rather what is described is a general system of collecting location and orientation information of traffic lights and use of the results in the form of a map to enable detection of the state of said lights at a later time. When reading the patent I got the feeling that this is solid engineering but I didn’t get the “hey this is clever” reaction which is a sort of indicator for inventiveness.

The claims are not limited to a large database that all the vehicles would use to get the traffic light location information, it would also cover saving the same information in the cars own systems. I.e. it would not be possible for your car to store information of where the lights are on the routes you often drive, that is unless it had a licence from google to use.

This application seems to be intended to create difficulties for anyone who wishes to create a map of traffic lights for the purpose of guiding automated vehicles. It could give Google an advantage as creating and especially maintaining such a map by other means could pose some difficulties. Secondly there is a possibility that if it is granted in its current form Google might be able to prevent others from using information of traffic light location to help real time detection of the light state. As part of a portfolio of automated driving patents it could have some value, although there are other methods of getting the same information to car systems. The nice thing about the mapping idea is that it requires very little liaison with authorities maintaining the traffic system.

If the world is going to move to fully automated vehicles traffic lights are probably not needed in the sense they are currently used. Thus this patent would only be useful during a transition period, but the transition could easily be longer than the duration of the protection a patent offers

It is a bit scary that the description gives information on known triangulation and image recognition technologies as this might open a lot of trolling opportunities when the claims are widely interpreted.

TIER 2: AVOIDING LICENSING

An alternate to the map described in this document could be to determine when the light changes occur and from several of these time stamps create a state machine with transitions at known times. The timing information could then be distributed from the cloud to vehicles on their way to the same intersection. Knowing which light should be active would make it a bit faster to find the fixtures from larger images that result from not knowing the location of the traffic light. This would not need a map of locations of the traffic lights, it would only be a map of traffic light state machines with much more lax accuracy requirements . Vehicles could also take advantage of this information to optimize speed, thus reducing maximum accelerations and likely speed and therefore also lowering the likelihood of accidents or at least make the results less severe.

In the discussion of background it is mentioned that efforts have been made to develop systems that use radio transmission of traffic light state but the infrastructure investment is seen as an obstacle. Why not use existing radio infra to transmit the information? A scheme where the traffic light state is available on the net and read through a cellular data connection would need less tampering with the infrastructure. This of course only works in places where the traffic lights are centrally controlled.

The obvious bypassing technique is to not have a map of traffic lights and scan for them continually in the same general direction where drivers look for them. The cost of this surely will become lower as more and more computational power becomes available. One way of avoiding the use of a map could be to ask the vehicles in front of you: where did they find the light. Vehicle to vehicle communications is likely going to be ubiquitous before driverless cars, so there is a good chance that at some point only software development is required to implement exchange of the information. Getting the advantage of making the map in good weather and lighting conditions is more difficult to achieve with other methods.

TIER 3: TECHNICAL ANALYSIS

The description offers a fair explanation of the intended system though most of the details must be known technology. Triangulation and related methods are a widely used technology as is identification of objects with roughly known characteristics from images. Saving the location and characteristics of the identified objects in a database that can be called a map is likewise a well known approach for representing data in an accessible format.

At one point there is talk about triangulation and at the same time about using a sphere to determine which labels (i.e. location of traffic light in an image) will be associated with each other. Later it is mentioned that this determination may be part of an analysis of an image sequence, using a template to follow the traffic light in the consecutive images. At some point a first location determination needs to be done to get a center for the uncertainty sphere. A circular logic seems to be in use.

Knowing the location of the traffic lights before detection will likely lower the false interpretation rate especially if the conditions at the time of detection are difficult: for example there is fog, difficult lighting conditions for the cameras or heavy rain. It will also lower the computational intensity and thus lower the cost. This may be a significant advantage.

Several different types of traffic lights are in use around the world but the description is very light on how these could be identified. This is especially a problem in the map creation phase as it is crucial to make correct interpretations. If successful this effort would make the map more valuable as the vehicle would only need to identify the traffic light fixture and could use the map to identify positions of different types of lights (arrows etc.)

Value of the description is lowered by some pretty standard patent speak, for example why draw a flowchart and then say the boxes can be in any order? Is it because the examiners like flow charts and not bullet point lists? In the current form it reduces the value of the flow chart to zero, all of the text it contains is already in the description.

While creating a system that does the mapping is certainly not a trivial undertaking I find it difficult to see what is the inventive step. The mix of patent speak and technical writing in the description could effectively hide it but I would argue that the description is pretty much what most skilled in the art would try after they realise that real time identification takes too much processing power and results in too many errors.

Generally the claims seem to refer to the text in the description part and to the images.

The claims curiously omit other than color based identification of the lights (for example 20), embedded image, shape, frequency etc. could also be used for identification. With LED traffic lights it might even be possible to do a software upgrade to make them blink fast enough to show this in a row read camera sensor. Further, the color identification scheme is lacking in detail. Color is mentioned but not intensity, if the position of each intended signal is known, then it is possible to identify the state from just the relative intensity of the three indicators. Further, depending on the color of the surrounding light being reflected from the traffic light and the color of the light emitted from the traffic light there might not be a large difference in color between the on and off states anyway.

 

Translate »