Optical granulometry is the process of measuring the different grain sizes in a granular material, based on a photograph. Technology has been created to analyze a photograph and create statistics based on what the picture portrays. This information is vital in maintaining machinery in various trades worldwide. Mining companies can use optical granulometry to analyze inactive or moving rock to quantify the size of these fragments. Forestry companies can zero in on wood chip sizes without stopping the production process, and minimize sizing errors. With more photoanalysis technologies being produced, mining companies have shown an increased interest in these types of systems because of their ability to maintain efficiency throughout the mining process. Companies are saving millions of dollars annually because of this new technology, and are cutting back on maintenance costs on equipment. In order for optical granulometry to be completely successful, an accurate photo must be taken – under sufficient lighting, and using proper technology – to obtain quantified results. If these requirements are met, an image analysis system can be implemented. == The process == Software uses four basic steps in determining the average size of material: See the Wikipedia article on Photoanalysis to see how mining, forestry and agricultural companies are using this technology to improve quality control techniques. == Smartphone-based, segmentation-free estimation of grain size distribution == Recently, a methodology has emerged by which soil grain size distribution can be inferred from optical images acquired with commodity smartphones by training convolutional neural networks to predict parameters of the distribution curve directly from the image, without explicit image segmentation . In this approach, a standardized image of a soil surface is captured under controlled conditions, preprocessed to reduce device-specific variability, and passed to a regression model that outputs the parameters of a cumulative distribution function e.g., a two-parameter Weibull curve. The resulting distribution can be used to derive geotechnical descriptors and class boundaries.
Visual Turing Test
The Visual Turing Test is “an operator-assisted device that produces a stochastic sequence of binary questions from a given test image”. The query engine produces a sequence of questions that have unpredictable answers given the history of questions. The test is only about vision and does not require any natural language processing. The job of the human operator is to provide the correct answer to the question or reject it as ambiguous. The query generator produces questions such that they follow a “natural story line”, similar to what humans do when they look at a picture. == History == Research in computer vision dates back to the 1960s when Seymour Papert first attempted to solve the problem. This unsuccessful attempt was referred to as the Summer Vision Project. The reason why it was not successful was because computer vision is more complicated than what people think. The complexity is in alignment with the human visual system. Roughly 50% of the human brain is devoted in processing vision, which indicates that it is a difficult problem. Later there were attempts to solve the problems with models inspired by the human brain. Perceptrons by Frank Rosenblatt, which is a form of the neural networks, was one of the first such approaches. These simple neural networks could not live up to their expectations and had certain limitations due to which they were not considered in future research. Later with the availability of the hardware and some processing power the research shifted to image processing which involves pixel-level operations, like finding edges, de-noising images or applying filters to name a few. There was some great progress in this field but the problem of vision which was to make the machines understand the images was still not being addressed. During this time the neural networks also resurfaced as it was shown that the limitations of the perceptrons can be overcome by Multi-layer perceptrons. Also in the early 1990s convolutional neural networks were born which showed great results on digit recognition but did not scale up well on harder problems. The late 1990s and early 2000s saw the birth of modern computer vision. One of the reasons this happened was due to the availability of key, feature extraction and representation algorithms. Features along with the already present machine learning algorithms were used to detect, localise and segment objects in Images. While all these advancements were being made, the community felt the need to have standardised datasets and evaluation metrics so the performances can be compared. This led to the emergence of challenges like the Pascal VOC challenge and the ImageNet challenge. The availability of standard evaluation metrics and the open challenges gave directions to the research. Better algorithms were introduced for specific tasks like object detection and classification. Visual Turing Test aims to give a new direction to the computer vision research which would lead to the introduction of systems that will be one step closer to understanding images the way humans do. == Current evaluation practices == A large number of datasets have been annotated and generalised to benchmark performances of difference classes of algorithms to assess different vision tasks (e.g., object detection/recognition) on some image domain (e.g., scene images). One of the most famous datasets in computer vision is ImageNet which is used to assess the problem of object level Image classification. ImageNet is one of the largest annotated datasets available and has over one million images. The other important vision task is object detection and localisation which refers to detecting the object instance in the image and providing the bounding box coordinates around the object instance or segmenting the object. The most popular dataset for this task is the Pascal dataset. Similarly there are other datasets for specific tasks like the H3D dataset for human pose detection, Core dataset to evaluate the quality of detected object attributes such as colour, orientation, and activity. Having these standard datasets has helped the vision community to come up with well performing algorithms for all these tasks. The next logical step is to create a larger task encompassing of these smaller subtasks. Having such a task would lead to building systems that would understand images, as understanding images would inherently involve detecting objects, localising them and segmenting them. == Details == The Visual Turing Test (VTT) unlike the Turing test has a query engine system which interrogates a computer vision system in the presence of a human co-ordinator. It is a system that generates a random sequence of binary questions specific to the test image, such that the answer to any question k is unpredictable given the true answers to the previous k − 1 questions (also known as history of questions). The test happens in the presence of a human operator who serves two main purposes: removing the ambiguous questions and providing the correct answers to the unambiguous questions. Given an Image infinite possible binary questions can be asked and a lot of them are bound to be ambiguous. These questions if generated by the query engine are removed by the human moderator and instead the query engine generates another question such that the answer to it is unpredictable given the history of the questions. The aim of the Visual Turing Test is to evaluate the Image understanding of a computer system, and an important part of image understanding is the story line of the image. When humans look at an image, they do not think that there is a car at ‘x’ pixels from the left and ‘y’ pixels from the top, but instead they look at it as a story, for e.g. they might think that there is a car parked on the road, a person is exiting the car and heading towards a building. The most important elements of the story line are the objects and so to extract any story line from an image the first and the most important task is to instantiate the objects in it, and that is what the query engine does. === Query engine === The query engine is the core of the Visual Turing Test and it comprises two main parts : Vocabulary and Questions ==== Vocabulary ==== Vocabulary is a set of words that represent the elements of the images. This vocabulary when used with appropriate grammar leads to a set of questions. The grammar is defined in the next section in a way that it leads to a space of binary questions. The vocabulary V {\displaystyle {\mathcal {V}}} consist of three components: Types of Objects T {\displaystyle {\mathcal {T}}} Type-dependent attributes of objects A ( t ) {\displaystyle {\mathcal {A}}(t)} Type-dependent relationships between two objects R ( t , t ′ ) {\displaystyle {\mathcal {R}}(t,t')} For Images of urban street scenes the types of objects include people, vehicle and buildings. Attributes refer to the properties of these objects, for e.g. female, child, wearing a hat or carrying something, for people and moving, parked, stopped, one tire visible or two tires visible for vehicles. Relationships between each pair of object classes can be either “ordered” or “unordered”. The unordered relationships may include talking, walking together and the ordered relationships include taller, closer to the camera, occluding, being occluded etc. Additionally all of this vocabulary is used in context of rectangular image regions w \in W which allow for the localisation of objects in the image. An extremely large number of such regions are possible and this complicates the problem, so for this test, regions at specific scales are only used which include 1/16 the size of image, 1/4 the size of image, 1/2 the size of image or larger. ==== Questions ==== The question space is composed of four types of questions: Existence questions: The aim of the existence questions is to find new objects in the image that have not been uniquely identified previously. They are of the form : Qexist = 'Is there an instance of an object of type t with attributes A partially visible in region w that was not previously instantiated?' Uniqueness questions: A uniqueness question tries to uniquely identify an object to instantiate it. Quniq = 'Is there a unique instance of an object of type t with attributes A partially visible in region w that was not previously instantiated?' The uniqueness questions along with the existence questions form the instantiation questions. As mentioned earlier instantiating objects leads to other interesting questions and eventually a story line. Uniqueness questions follow the existence questions and a positive answer to it leads to instantiation of an object. Attribute questions: An attribute question tries to find more about the object once it has been instantiated. Such questions can query about a single attribute, conjunction of two attributes or disjunction of two attributes. Qatt(ot) = {'Does object ot have attribute a?' , 'Does object
Vibe coding
Vibe coding is a software development practice assisted by artificial intelligence (AI) where the software developer describes a project or task in a prompt to a large language model (LLM), which generates source code automatically. Vibe coding may involve accepting AI-generated code without thorough review of the output, instead relying on results and follow-up prompts to guide changes. The term was coined in February 2025 by computer scientist Andrej Karpathy, a co-founder of OpenAI and former AI leader at Tesla. Merriam-Webster listed the term in March 2025 as a "slang & trending" expression. It was named the Collins English Dictionary Word of the Year for 2025. Advocates of vibe coding say that it allows even amateur programmers to produce software without the extensive training and skills required for software engineering. Critics point out a lack of accountability, maintainability, and the increased risk of introducing security vulnerabilities in the resulting software. == Definition == The concept refers to a coding approach that relies on LLMs, allowing programmers to generate working code by providing natural language descriptions rather than manually writing in a formal programming language. Karpathy described it as a form of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists". When vibe coding, the programmer guides, tests, and gives feedback about the AI-generated source code, rather than manually writing code. The concept of vibe coding elaborates on Karpathy's claim from 2023 that "the hottest new programming language is English", meaning that the capabilities of LLMs were such that humans would no longer need to learn specific programming languages to command computers. Some commentators argue that a key to the definition is a lack of knowledge about the code, and that thorough review and testing is incompatible with the definition of vibe coding. Programmer Simon Willison said: "If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding in my book—that's using an LLM as a typing assistant." == Reception and use == In February 2025, New York Times journalist Kevin Roose, who is not a professional coder, experimented with vibe coding to create several small-scale applications. He described these as "software for one" due to the ability to personalize the software. However, Roose also stated that the results are often limited and prone to errors. In one case, the AI-generated code fabricated fake reviews for an e-commerce site. In response to Roose, cognitive scientist Gary Marcus said that the algorithm that generated Roose's LunchBox Buddy app had presumably been trained on existing code for similar tasks. Marcus said that Roose's enthusiasm stemmed from reproduction, not originality. In March 2025, Y Combinator reported that 25% of startup companies in its Winter 2025 batch had codebases that were 95% AI-generated, reflecting a shift toward AI-assisted development within newer startups. The question asked was about AI-generated code in general, and not specifically about vibed code. Inspired by "vibe coding", The Economist suggested the term "vibe valuation" to describe the very large valuations of AI startups by venture capital firms that ignore accepted metrics such as annual recurring revenue. In June 2025, Andrew Ng took issue with the term, saying that it misleads people into assuming that software engineers just "go with the vibes" when using AI tools to create applications. In July 2025, The Wall Street Journal reported that vibe coding was being adopted by professional software engineers for commercial use cases. In July 2025, SaaStr founder documented his negative experiences with vibe coding: Replit's AI agent deleted a database despite explicit instructions not to make any changes. In September 2025, Fast Company reported that the "vibe coding hangover" is upon us, with senior software engineers citing "development hell" when working with AI-generated code. It was reported in January 2026 that Linus Torvalds had made use of Google Antigravity to vibe code a tool component of his AudioNoise random digital audio effects generator. Torvalds explained in the project's README file that "the Python visualizer tool has been basically written by vibe-coding". == Criticism == === Quality of code and security issues === Vibe coding has raised concerns about understanding and accountability. Developers may use AI-generated code without comprehending its functionality, leading to undetected bugs, errors, or security vulnerabilities. While this approach may be suitable for prototyping or "throwaway weekend projects" as Karpathy originally envisioned, it is considered by some experts to pose risks in professional settings, where a deep understanding of the code is crucial for debugging, maintenance, and security. Ars Technica cites Simon Willison, who stated: "Vibe coding your way to a production codebase is clearly risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial." In May 2025, Lovable, a Swedish vibe coding app, was reported to have security vulnerabilities in the code it generated, with 170 out of 1,645 Lovable-created web applications having an issue that would allow personal information to be accessed by anyone. In October 2025 Veracode released a study that showed that over the last 3 years LLMs had become dramatically better at generating functional code, but that the security of generated code had generally not improved. Moreover, larger models were not better than small ones at generating secure code. There was a small increase in security from the OpenAI reasoning models, but not in other reasoning models, and this increase was nothing like the improvement in generated functionality. In December 2025, computer security researcher Etizaz Mohsin discovered a security flaw in the Orchids vibe coding platform, which he demonstrated to a BBC News reporter in February 2026. A December 2025 analysis by CodeRabbit of 470 open-source GitHub pull requests found that code that was co-authored by generative AI contained approximately 1.7 times more "major" issues compared to human-written code. The study revealed that AI co-authored code showed elevated rates of logic errors, including incorrect dependencies, flawed control flow, misconfigurations (75% more common), and security vulnerabilities (2.74x higher). Additionally, they also reported high code readability issues, including formatting errors and naming inconsistencies. === Code maintainability and technical debt === Vibe coding has the potential of making code harder to maintain in the longer term, leading to technical debt. In early 2025, GitClear published the results of a longitudinal analysis of 211 million lines of code changes from 2020 to 2024. They found that the volume of code refactoring dropped from 25% of changed lines in 2021 to under 10% by 2024, code duplication increased approximately four times in volume, copy-pasted code exceeded moved code for the first time in two decades, and code churn (prematurely merged code getting rewritten shortly after merging) nearly doubled. === Task complexity and developer productivity === Generative AI is highly capable of handling simple tasks like basic algorithms. However, such systems struggle with more novel, complex coding problems like projects involving multiple files, poorly documented libraries, or safety-critical code. In July 2025, METR, an organization that evaluates frontier models, ran a randomized controlled trial to understand developer productivity involving generative AI programming tools available in early 2025. They found that experienced open-source developers were 19% slower when using AI coding tools, despite predicting they would be 24% faster and still believing afterward they had been 20% faster. === Challenges with debugging === LLMs generate code dynamically, and the structure of such code may be subject to variation. In addition, since the developer did not write the code, the developer may struggle to understand its syntax and concepts. === Impact on open-source software === In January 2026, a paper authored by experts from several universities titled "Vibe Coding Kills Open Source" argued that vibe coding has negative impact on the open-source software ecosystem. The authors say that increased vibe coding reduces user engagement with open-source maintainers, which has hidden costs for said maintainers. Speaking with The Register about their paper, the authors argued:"Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns," the authors argue. "When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers e
Supreme Commander (video game)
Supreme Commander (sometimes SupCom) is a 2007 real-time strategy video game designed by Chris Taylor and developed by his company, Gas Powered Games. The game is considered to be a spiritual successor, not a direct sequel, to Taylor's 1997 game Total Annihilation. First announced in the August 2005 edition of PC Gamer magazine, the game was released in Europe on February 16, 2007, and in North America on February 20. The standalone expansion Supreme Commander: Forged Alliance was released on November 6 of the same year. The sequel, Supreme Commander 2, was released in 2010. Nowadays, the original Supreme Commander is played through the community client called Forged Alliance Forever; the game has been further developed and balanced, and offers a wide variety of community mods. The gameplay of Supreme Commander focuses on using a giant bipedal mech called an Armored Command Unit (ACU), the so-called "Supreme Commander", to build a base, upgrading units to reach higher technology tiers, and conquering opponents. The player can command one of three factions: the Aeon Illuminate, the Cybran Nation, or the United Earth Federation (UEF). The expansion game added the Seraphim faction. Supreme Commander was highly anticipated in pre-release previews, and was well received by critics, with a Metacritic average of 86 out of 100. == Gameplay == Supreme Commander, like its spiritual predecessors, Total Annihilation and Spring, begins with the player solely possessing a single, irreplaceable construction unit called the "Armored Command Unit," or ACU, the titular Supreme Commander. Normally the loss of this unit results in the loss of the game (Skirmish missions can be set for a variety of victory conditions). These mech suits are designed to be transported through quantum gateways across the galaxy and contain all the materials and blueprints necessary to create an army from a planet's native resources in hours. All standard units except Commanders and summoned Support Commanders (sACU) are self-sufficient robots. All units and structures belong to one of four technology tiers, or "Tech" levels, each tier being stronger and/or more efficient than the previous. Certain lower-tier structures can be upgraded into higher ones without having to rebuild them. The first tier is available at the start of the game and consists of small, relatively weak units and structures. The second tier expands the player's abilities greatly, especially in terms of stationary weapons and shielding, and introduces upgraded versions of tier one units. The third tier level has very powerful assault units designed to overcome the fortifications of the most entrenched player. The fourth tier is a limited range of "experimental" technology. These are usually massive units which take a lot of time and energy to produce, but provide a significant tactical advantage. Supreme Commander features a varied skirmish AI. The typical Easy' and Normal modes are present, but the Hard difficulty level has four possible variants. Horde AI will swarm the player with hordes of lower level units, Tech AI will upgrade its units as fast as possible and assault the player with advanced units, the Balanced AI attempts to find a balance between the two, and the Supreme AI decides which of the three hard strategies is best for the map. The single player campaign consists of eighteen missions, six for each faction. The player is an inexperienced Commander who plays a key role in their faction's campaign to bring the "Infinite War" to an end. Despite the low number of campaign missions, each mission can potentially last hours. At the start of a mission, objectives are assigned for the player to complete. Once the player accomplishes them, the map is expanded, sometimes doubling or tripling in size, and new objectives are assigned. As the mission is commonly divided into three segments, the player will often have to overcome several enemy positions to achieve victory. === Resource management === Because humans have developed replication technology, making advanced use of rapid prototyping and nanotechnology, only two types of resources are required to wage war: Energy and Mass. Energy is obtained by constructing power generators on any solid surface (except fuel generators, which can only be built on fuel deposits), while Mass is obtained either by placing mass extractors on limited mass deposit spots (the most efficient method, although it requires map control) or by building mass fabricators to convert energy into mass. Constructor units can gather energy by "reclaiming" it from organic debris such as trees and mass from rocks and wrecked units. Each player has a certain amount of resource storage, which can be expanded by the construction of storage structures. This gives the player reserves in times of shortage or allows them to stockpile resources. If the resource generation exceeds the player's capacity, the material is wasted. On the contrary, if the storages are depleted and the demand of one of the resources exceeds the production, then all the productions speed is reduced. In addition, if an energy deficit occurs, shields will stop working. An adjacency system allows certain structures to benefit from being built directly adjacent to others. Energy-consuming structures will use less energy when built adjacent to power generators and power generators will produce more energy when built adjacent to power storage structures. The same applies to their mass-producing equivalents. Likewise, factories will consume less energy and mass when built adjacent to power generators and mass fabricators/extractors, respectively. However, by placing structures in close proximity, they become more vulnerable to collateral damage if an adjacent structure is destroyed. Furthermore, most resource generation structures can cause chain reactions when destroyed (especially Tier III structures, which produce large amounts of resources but often have large detonations that can wipe out a nearby army). === Warfare === Supreme Commander uses a "strategic zoom" system that allows the player to seamlessly zoom from a detailed close up view of an individual unit all the way out to a view of the entire map, at which point it resembles a fullscreen version of the minimap denoting individual units with icons. The camera also has a free movement mode and can be slaved to track a selected unit and there is a split screen mode which also supports multiple monitors. This system allows Supreme Commander to use vast maps up to 80 km x 80 km, with players potentially controlling a thousand units each. Units in Supreme Commander are built to scale as they would be in the real world. For example, battleships dwarf submarines. Late into the game, the larger "experimental" units, such as the Cybran Monkeylord, an enormous spider-shaped assault unit, can actually crush smaller enemy units by stepping on them. Because of the wide range of planets colonized by humanity in the setting, the theatres of war range from desert to arctic, and all battlespaces are employed. Technologies emerging in modern warfare are frequently employed in Supreme Commander. For example, stealth technology and both tactical and strategic missile and missile defense systems can be used. Supreme Commander introduced several innovations designed to reduce the amount of micromanagement inherent in many RTS games. Engineers units have the command "assist", that will help follow other engineers and help them finish their orders or improve production rate of factories. In addition, engineers with the order "patrol" will repair units, buildings and recycle wrecks in their along their patrol route. Holding the shift key causes any orders given to a unit (or group of units) to be queued. In this manner a unit may be ordered to attack several targets in succession, or to make best speed to a given point on the map and then attack towards a specified location engaging any hostiles it encounters along the way. After orders have been issued, holding the shift key causes all issued orders to be displayed on the map where they can be subsequently modified to accommodate a change of plan. Further, when a unit is ordered to attack a target, the player can issue an order to perform a coordinated attack to another unit. This order coordinates the arrival time of the units at the target automatically by adjusting the speed of the units involved. As in other RTS games, air transports can be used to convey units to specified destinations, in Supreme Commander though by shift queuing orders a transport containing several units can be ordered to drop specific units at subsequent waypoints. An air transport can also be ordered to create a ferry route, an airbridge wherein any land units ordered to the start of the ferry route will be conveyed by the air transport to the specified destination. The output from a production factory can be routed to a ferry route causing all units co
Tamarin Prover
Tamarin Prover is a computer software program for formal verification of cryptographic protocols. It has been used to verify Transport Layer Security 1.3, ISO/IEC 9798, DNP3 Secure Authentication v5, WireGuard, and the PQ3 Messaging Protocol of Apple iMessage. Tamarin is an open source tool, written in Haskell, built as a successor to an older verification tool called Scyther. Tamarin has automatic proof features, but can also be self-guided. In Tamarin lemmas that representing security properties are defined. After changes are made to a protocol, Tamarin can verify if the security properties are maintained. The results of a Tamarin execution will either be a proof that the security property holds within the protocol, an example protocol run where the security property does not hold, or Tamarin could potentially fail to halt.
Cloud-based integration
Cloud-based integration is a form of systems integration business delivered as a cloud computing service that addresses data, process, service-oriented architecture (SOA) and application integration. == Description == Integration platform as a service (iPaaS) is a suite of cloud services enabling customers to develop, execute and govern integration flows between disparate applications. Under the cloud-based iPaaS integration model, customers drive the development and deployment of integrations without installing or managing any hardware or middleware. The iPaaS model allows businesses to achieve integration without big investment into skills or licensed middleware software. iPaaS used to be regarded primarily as an integration tool for cloud-based software applications, used mainly by small to mid-sized business. Over time, a hybrid type of iPaaS—hybrid-IT iPaaS—that connects cloud to on-premises, is becoming increasingly popular. Additionally, large enterprises are exploring new ways of integrating iPaaS into their existing IT infrastructures. Cloud integration was created to break down the data silos, improve connectivity and optimize the business process. Cloud integration has increased in popularity as the usage of Software as a Service solutions has grown. Prior to the emergence of cloud computing in the early 2000s, integration could be categorized as either internal or business to business (B2B). Internal integration requirements were serviced through an on-premises middleware platform and typically utilized a service bus to manage exchange of data between systems. B2B integration was serviced through EDI gateways or value-added network (VAN). The advent of SaaS applications created a new kind of demand which was met through cloud-based integration. Since their emergence, many such services have also developed the capability to integrate legacy or on-premises applications, as well as function as EDI gateways. The following essential features were proposed by one marketing company: Deployed on a multi-tenant, elastic cloud infrastructure Subscription model pricing (operating expense, not capital expenditure) No software development (required connectors should already be available) Users do not perform deployment or manage the platform itself Presence of integration management and monitoring features The emergence of this sector led to new cloud-based business process management tools that do not need to build integration layers - since those are now a separate service. Drivers of growth include the need to integrate mobile app capabilities with proliferating API publishing resources and the growth in demand for the Internet of things functionalities as more 'things' connect to the Internet.
Death of Elaine Herzberg
The death of Elaine Herzberg (August 2, 1968 – March 18, 2018) was the first recorded case of a pedestrian fatality involving a self-driving car, after a collision that occurred late in the evening of March 18, 2018. Herzberg was pushing a bicycle across a four-lane road in Tempe, Arizona, United States, when she was struck by an Uber test vehicle, which was operating in self-drive mode with a human safety backup driver sitting in the driving seat. Herzberg was taken to the local hospital where she died of her injuries. Following the fatal incident, the National Transportation Safety Board (NTSB) issued a series of recommendations and sharply criticized Uber. The company suspended testing of self-driving vehicles in Arizona, where such testing had been approved since August 2016. Uber chose not to renew its permit for testing self-driving vehicles in California when it expired at the end of March 2018. Uber resumed testing in December 2018, starting in Pittsburgh, Pennsylvania. In March 2019, Arizona prosecutors ruled that Uber was not criminally responsible for the crash. The back-up driver of the vehicle was charged with negligent homicide, pled guilty to endangerment, and was sentenced to three years' probation. While Herzberg was the first pedestrian killed by a self-driving car, driver Gao Yaning died in a Tesla semi-autonomous car two years earlier. A reporter for The Washington Post compared Herzberg's fate with that of Bridget Driscoll who, in the United Kingdom in 1896, was the first pedestrian to be killed by an automobile. The Arizona incident has magnified the importance of collision avoidance systems for self-driving vehicles. == Collision summary == Herzberg was crossing Mill Avenue (North) from west to east, approximately 360 feet (110 m) south of the intersection with Curry Road, outside the designated pedestrian crosswalk, close to the Red Mountain Freeway. She was pushing a bicycle laden with shopping bags, and had crossed at least two lanes of traffic when she was struck at approximately 9:58 pm MST (UTC−07:00) by a prototype Uber self-driving car based on a Volvo XC90, which was traveling north on Mill. The vehicle had been operating in autonomous mode since 9:39 pm, nineteen minutes before it struck and killed Herzberg. The car's human safety backup driver, Rafaela Vasquez, did not intervene in time to prevent the collision. Vehicle telemetry obtained after the crash showed that the human operator responded by moving the steering wheel less than a second before impact, and she engaged the brakes less than a second after impact. == Cause investigation == The county district attorney's office recused itself from the investigation, due to a prior joint partnership with Uber promoting their services as an alternative to driving under the influence of alcohol. Accounts differ on the speed limit at the place of the incident. According to Tempe police the car was traveling in a 35 mph (56 km/h) zone, but this is contradicted by a posted speed limit of 45 mph (72 km/h). The National Transportation Safety Board (NTSB) sent a team of federal investigators to gather data from vehicle instruments, and to examine vehicle condition along with the actions taken by the safety driver. Their preliminary findings were substantiated by multiple event data recorders and proved the vehicle was traveling 43 miles per hour (69 km/h) when Herzberg was first detected 6 seconds (378 feet (115 m)) before impact; during 4.7 seconds the self driving system did not infer that emergency braking was needed. A vehicle traveling 43 mph (69 km/h) can generally stop within 89 feet (27 m) once the brakes are applied. The machine needed to be 1.3 seconds (82 feet (25 m)) away prior to discerning that emergency braking was required, whereas at least that much distance was required to stop. The system failed to behave properly. A total stopping distance of 76 feet itself would imply a safe speed under 25 mph (40 km/h). Human intervention was still legally required. Computer perception–reaction time would have been a speed limiting factor had the technology been superior to humans in ambiguous situations; however, the nascent computerized braking technology was disabled the day of the crash, and the machine's apparent 4.7-second perception–reaction (alarm) time allowed the car to travel 250 feet (76 m). Video released by the police on March 21 showed the safety driver was not watching the road moments before the vehicle struck Herzberg. === Environment === In widely disseminated remarks that would shape the narrative about the crash, which were later seen as prejudicial and subsequently contradicted by her own department, Tempe Police Chief Sylvia Moir was quoted stating that the collision was "unavoidable" based on the initial police investigation, which included a review of the video captured by an onboard camera. Moir faulted Herzberg for crossing the road in an unsafe manner: "It is dangerous to cross roadways in the evening hour when well-illuminated, managed crosswalks are available." According to Uber, safety drivers were trained to keep their hands very close to the wheel all the time while driving the vehicle so they were ready to quickly take control if necessary. The driver said it was like a flash, the person walked out in front of them. His [sic] first alert to the collision was the sound of the collision. [...] it's very clear it would have been difficult to avoid this collision in any kind of mode (autonomous or human-driven) based on how she came from the shadows right into the roadway. Tempe police released video on March 21, 2018, showing footage recorded by two onboard cameras: one forward-looking, and one capturing the safety driver's actions. The forward-facing video shows that the self-driving car was traveling in the far right lane when it struck Herzberg. The driver-facing video shows the safety driver was looking down prior to the collision. The Uber operator is responsible for intervening and taking manual control when necessary as well as for monitoring diagnostic messages, which are displayed on a screen in the center console. In an interview conducted after the crash with NTSB, the driver stated she was monitoring the center stack at the time of the collision. After the Uber video was released, journalist Carolyn Said noted the police explanation of Herzberg's path meant she had already crossed two lanes of traffic before she was struck by the autonomous vehicle. The Marquee Theatre and Tempe Town Lake are west of Mill Avenue, and pedestrians commonly cross mid-street without detouring north to the crosswalk at Curry. According to reporting by the Phoenix New Times, Mill Avenue contains what appears to be a brick-paved path in the median between the northbound and southbound lanes; however, posted signs prohibit pedestrians from crossing in that location. When the second of the Mill Avenue bridges over the town lake was added in 1994 for northbound traffic, the X-shaped crossover in the median was installed to accommodate the potential closing of one of the two road bridges. The purpose of this brick-paved structure is purely to divert cars from one side to the other if a bridge is closed to traffic, and although it may look like a crosswalk for pedestrians, it is in fact a temporary roadway with vertical curbs and warning signs. === Software issues === Michael Ramsey, a self-driving car expert with Gartner, characterized the video as showing "a complete failure of the system to recognize an obviously seen person who is visible for quite some distance in the frame. Uber has some serious explaining to do about why this person wasn't seen and why the system didn't engage." The NTSB preliminary report, however, noted that the software did order the car to brake 1.3 seconds before the collision. A video shot from the vehicle's dashboard camera showed the safety driver looking down, away from the road. It also appeared that the driver's hands were not hovering above the steering wheel, which is what drivers are instructed to do so they can quickly retake control of the car. Uber had moved from two employees in every car to one. The paired employees had been splitting duties: one ready to take over if the autonomous system failed, and another to keep an eye on what the computers were detecting. The second person was responsible for keeping track of system performance as well as labeling data on a laptop computer. Mr. Kallman, the Uber spokesman, said the second person was in the car for purely data related tasks, not safety. When Uber moved to a single operator, some employees expressed safety concerns to managers, according to the two people familiar with Uber's operations. They were worried that going solo would make it harder to remain alert during hours of monotonous driving. The recorded telemetry showed the system had detected Herzberg six seconds before the crash, and classified her first as an unknown object, then as a