Roborace was a competition with autonomously driving, electrically powered vehicles. Founded in 2015 by Denis Sverdlov, it aimed to be the first global championship for autonomous cars. From 2017 to 2019, the official CEO was 2016–17 Formula E champion, Lucas Di Grassi, who later became a member of Roborace’s supervisory board. The series tested their technology and race formats at FIA Formula E Championship events during 2016–2018. In 2019 Roborace organized Season Alpha, which consisted of 4 trial racing events with several independent teams competing against each other for the first time. In 2020–21 Roborace held Season Beta with 7 competing teams. All teams utilized the same chassis and powertrain, but they had to develop their own real-time computing algorithms and artificial intelligence technologies. In May 2022, Arrival, the owner of Roborace, confirmed that they were no longer continuing the Roborace programme, but that they were hoping to find alternative funding. In February 2024, after getting its stock delisted from the Nasdaq, Arrival's UK division entered administration, with future plans of a sale of Arrival and all of its affiliated assets. == Cars == === Robocar === The world's first purpose-built autonomous racing car, Robocar, was designed by Daniel Simon, who previously worked on vehicles for movies such as Tron: Legacy and Oblivion, as well as designing the livery for the 2011 HRT Formula One car. Michelin is the official tyre supplier, and the internal computing processors (Drive PX 2) are Nvidia. The chassis itself is shaped like a teardrop, improving aerodynamic efficiency. The car weighs around 1350 kg and is 4.8 metres (16 ft) long and 2 metres (6.6 ft) wide. It has four electric motors, each with a power of 135 kW producing over 500 hp combined, and utilizes a 840V battery. For navigation, it relies on a mixture of optical systems, radars, lidars and ultrasonic sensors. The vehicle has been demonstrated at speeds of almost 300 km/h (190 mph). === DevBot === Development of the Robocar started in early 2016, with a first outing of a test vehicle, the so-called DevBot, following in the summer of the same year. The test car consisted of the same internal units (battery, motor, electronics) used in the Robocar, but were placed in the chassis of a Ginetta LMP3 car without an engine cover in order to provide better cooling and access. DevBot saw its first public outing at the Formula E pre-season tests in Donington Park in August 2016. After battery issues in Hong Kong caused the development team to abandon their demonstration run, the DevBot successfully drove twelve laps around the Moulay El Hassan Formula E circuit in Marrakesh. Other test tracks included Michelin's testing ground in Ladoux and the Silverstone Stowe Circuit. During testing ahead of the 2017 Buenos Aires ePrix, two DevBot cars raced against each other autonomously, resulting in one of the vehicles crashing on a corner. During the 2017–18 Formula E season, Roborace pitched pro-drifter Ryan Tuerck against a DevBot at the Rome ePrix. At the Berlin ePrix, Roborace held the Human + Machine Challenge, the first race for combined teams of human drivers and AIs using a pair of Devbots. === DevBot 2.0 === An upgraded version of DevBot was announced in late 2018, and after private testing made its public debut in 2019 at the inaugural Season Alpha event. DevBot 2.0 uses the same technology as both Robocar and DevBot, with the main changes being a conversion to being driven on the rear axle only, a lower position for the driver for safety reasons and a bespoke composite bodywork. == Seasons == === Testing === ==== 2016–17 Formula E season ==== Roborace appeared at a number of Formula E events during the 2016–17 Formula E season. However, in this period only test drives with two different DevBots took place. Within the framework of the 2017 Buenos Aires ePrix both DevBot vehicles drove against each other on a race track for the first time. There were also DevBot demonstrations at the 2016 Marrakesh ePrix, 2017 Berlin ePrix, 2017 New York City ePrix and 2017 Montreal ePrix. At the 2017 Paris ePrix, the developers also let a Robocar onto the track for the first time, even though the vehicle only drove the track at walking speed. ==== 2017–18 Formula E season ==== At the start of the 2017/18 Formula E season, the Roborace developers once again tested the DevBot during a public time trial between the Roborace CI and the TV presenter Nicki Shields at the 2017 Hong Kong ePrix. As part of a similar time trial at the 2018 Rome ePrix, drift professional Ryan Tuerck also tested the DevBot. The Human + Machine Challenge was created for the Formula E race on the Berlin ePrix. A team of doctoral students from the Technical University of Munich (TUM) and the University of Pisa programmed the software for the Devbot to drive autonomously around the circuit in Berlin. Afterwards both teams in combination with a human driver competed in a public time trial. The vehicle of the team of the Technical University of Munich finished the Human + Machine Challenge with an average lap time of 91.59 seconds, almost four seconds faster than that of the University of Pisa with 95.36 seconds and thus won the Challenge. At the Goodwood Festival of Speed, Robocar became the first ever fully autonomous race car to complete the Goodwood Hill Climb. The vehicle completed the first official autonomous run on 13 July 2018 within the framework of the event. === Season Alpha (2019) === Season Alpha took place at various locations in Europe and North America with the aim of testing several competition formats using the new DevBot 2.0. The first event was held at the Circuito Monteblanco in Spain, and featured the first race between two fully autonomous cars. The events were not broadcast live, instead short clips on YouTube were released. Two teams were competing: Arrival and the Technical University of Munich. On 7 July 2019, the Roborace DevBot 2.0 car set the first ever autonomous official timed run at Goodwood Festival of Speed, with a time of 66.96 s and a top speed of 162.8 km/h (101.2 mph). This is currently the record for autonomous vehicles. Roborace also set the Guinness World Record for having the fastest autonomous car in the world. The Robocar reached a speed of 282.42 km/h (175.49 mph). === Season Beta (2020–21) === The second testing season took place at various locations between September 2020 and October 2021, featuring 16 races and involving mixed reality elements dubbed "Roborace Metaverse", which is based on Roborace's patented technology. The program of Season Beta competitions has gradually complicating rules arranged in a progression of so-called missions. Each mission consists of two racing rounds — one round per day. A mission plan issued by Roborace for each mission defines its objectives, rules, and point-scoring system. The key objective of Season Beta is to come to the point when the majority of competing teams have developed sufficient capability for wheel-to-wheel racing in Season 1. There were 7 teams competing in Season Beta: Arrival Racing (UK/Russia), Autonomous Racing Graz (Austria), MIT Driverless (United States), Acronis SIT (Switzerland), University of Pisa (Italy), PoliMOVE (Italy), CMU (United States).
BeyondCorp
BeyondCorp is an implementation of zero-trust computer security concepts creating a zero trust network. It is created by Google. == Background == It was created in response to the 2009 Operation Aurora. An open source implementation inspired by Google's research paper on an access proxy is known as "transcend". Google documented its Zero Trust journey from 2014 to 2018 through a series of articles in the journal ;login:. Google called their ZT network "BeyondCorp". Google implemented a Zero Trust architecture on a large scale, and relied on user and device credentials, regardless of location. Data was encrypted and protected from managed devices. Unmanaged devices, such as BYOD, were not given access to the BeyondCorp resources. == Design and technology == BeyondCorp utilized a zero trust security model, which is a relatively new security model that it assumes that all devices and users are potentially compromised. This is in contrast to traditional security models, which rely on firewalls and other perimeter defenses to protect sensitive data. === Trust === The corporate network grants no inherent trust, and all internal apps are accessed via the BeyondCorp system, regardless of whether the user is in a Google office or working remotely. BeyondCorp is related to Zero Trust architecture as it implements a true Zero Trust network, where all access is granted on identity, device, and authentication, based on robust underlying device and identity data sources. BeyondCorp works by using a number of security policies including authentication, authorization, and access control to ensure that only authorized users can access corporate resources. Authentication verifies the identity of the user, authorization determines whether the user has permission to access the requested resource, and access control policies restrict what the user can do with the resource. ==== Trust Inferrer ==== One of the main components in BeyondCorp's implementation is the Trust Inferrer. The Trust Inferrer is a security component (typically software) that looks at information about a user's device, like a computer or phone, to decide how much it can be trusted to access certain resources like important company documents. The Trust Inferrer checks things like the security of the device, whether it has the right software installed, and if it belongs to an authorized user. Based on all this information, the Trust Inferrer decides what the device can access and what it can't. === Security mechanisms === Unlike traditional VPNs, BeyondCorp's access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or “tiers,” of access. === Device Inventory Database === BeyondCorp utilized a Device Inventory Database and Device Identity that uniquely identifies a device through a digital certificate. Any changes to the device are recorded in the Device Inventory Database. The certificate is used to uniquely identify a device; however, additional information is required to grant access privileges to a resource. === Access Control Engine === Another important component of BeyondCorp's implementation is the Access Control Engine. Think of this as the brain of the Zero Trust architecture. The Access Control Engine is like a traffic cop standing at an intersection. Its job is to make sure that only authorized devices and users are allowed to access specific resources (like files or applications) on the network. It checks the access policy (the rules that say who can access what), the device's state (like whether it has the right software updates or security settings), and the resources being requested. Then it makes a decision on whether to grant or deny access based on all of this information. It helps ensure that only the right people and devices are allowed access to the network, which helps keep things secure. The Access Control Engine utilizes the output from the Trust Inferrer and other data that is fed into its system. == Usage == One of the first things Google did to implement a Zero Trust architecture was to capture and analyze network traffic. The purpose of analyzing the traffic was to build a baseline of what typical network traffic looked like. In doing so, BeyondCorp also discovered unusual, unexpected, and unauthorized traffic. This was very useful because it gave the BeyondCorp engineers critical information that assisted them in reengineering the system in a secure manner. Some of the benefits BeyondCorp realized by adopting a Zero Trust architecture include the ability to allow their employees to work securely from any location. It reduces the risk of data breaches since data and applications are protected and users and devices are constantly being verified. The Zero Trust architecture is scalable and can be adapted to the changing needs of the businesses and their users. Especially relevant in today's work-from-home era, BeyondCorp allows employees to access enterprise resources securely from any location, without the need for traditional VPNs.
Phase congruency
Phase congruency is a measure of feature significance in computer images, a method of edge detection that is particularly robust against changes in illumination and contrast. == Foundations == Phase congruency reflects the behaviour of the image in the frequency domain. It has been noted that edgelike features have many of their frequency components in the same phase. The concept is similar to coherence, except that it applies to functions of different wavelength. For example, the Fourier decomposition of a square wave consists of sine functions, whose frequencies are odd multiples of the fundamental frequency. At the rising edges of the square wave, each sinusoidal component has a rising phase; the phases have maximal congruency at the edges. This corresponds to the human-perceived edges in an image where there are sharp changes between light and dark. == Definition == Phase congruency compares the weighted alignment of the Fourier components of a signal A n {\displaystyle A_{\rm {n}}} with the sum of the Fourier components. P C ( t ) = max ϕ ¯ ∑ n A n cos ( ϕ n ( t ) − ϕ ¯ ) ∑ n A n {\displaystyle PC(t)=\max _{\bar {\phi }}{\frac {\sum _{\rm {n}}A_{\rm {n}}\cos(\phi _{\rm {n}}(t)-{\bar {\phi }})}{\sum _{\rm {n}}A_{n}}}} where ϕ n {\displaystyle \phi _{\rm {n}}} is the local or instantaneous phase as can be calculated using the Hilbert transform and A n {\displaystyle A_{\rm {n}}} are the local amplitude, or energy, of the signal. When all the phases are aligned, this is equal to 1. Several ways of implementing phase congruency have been developed, of which two versions are available in open source, one written for MATLAB and the other written in Java as a plugin for the ImageJ software. Given the different notations used for its formulation, a unified version has been recently presented, where a methodology for the parameter tuning is also presented. == Advantages == The square-wave example is naive in that most edge detection methods deal with it equally well. For example, the first derivative has a maximal magnitude at the edges. However, there are cases where the perceived edge does not have a sharp step or a large derivative. The method of phase congruency applies to many cases where other methods fail. A notable example is an image feature consisting of a single line, such as the letter "l". Many edge-detection algorithms will pick up two adjacent edges: the transitions from white to black, and black to white. On the other hand, the phase congruency map has a single line. A simple Fourier analogy of this case is a triangle wave. In each of its crests there is a congruency of crests from different sinusoidal functions. == Disadvantages == Calculating the phase congruency map of an image is very computationally intensive, and sensitive to image noise. Techniques of noise reduction are usually applied prior to the calculation.
Facial age estimation
Facial age estimation is the use of artificial intelligence to estimate the age of a person based on their facial features. Computer vision techniques are used to analyse the facial features in the images of millions of people whose age is known and then deep learning is used to create an algorithm that tries to predict the age of an unknown person. The key use of the technology is to prevent access to age-restricted goods and services. Examples include restricting children from accessing internet pornography, checking that they meet a mandatory minimum age when registering for an account on social media, or preventing adults from accessing websites, online chat or games designed only for use by children. The technology is distinct from facial recognition systems as the software does not attempt to uniquely identify the individual. Researchers have applied neural networks for age estimation since at least 2010. == Evaluation == An ongoing study by the National Institute of Standards and Technology (NIST) entitled 'Face Analysis Technology Evaluation' seeks to establish the technical performance of prototype age estimation algorithms submitted by academic teams and software vendors including Brno University of Technology, Czech Technical University in Prague, Dermalog, IDEMIA, Incode Technologies Inc, Jumio, Nominder, Rank One Computing, Unissey and Yoti. == Public sector use == The UK government has explored using facial age estimation at the UK border as an alternative to bone X-rays and MRI scans when determining child status of asylum seekers. == Commercial use == Commercial users of facial age estimation include Instagram and OnlyFans. In January 2025, John Lewis & Partners announced that had started using the technology to check the age of people shopping for knives on its website, to comply with UK legislation to limit knife crime. In the UK, several supermarket chains have taken part in Home Office trials of the technology to automate the checking of a customer's age when buying age-restricted goods such as alcohol. UK legislation introduced in January 2025 mandates robust forms of age verification hosting adult content viewable in the UK by July 2025. Allowable methods include facial age estimation. == Criticism == Adam Schwartz, a lawyer for the Electronic Frontier Foundation, criticized the use of facial age estimation software, noting its inaccuracy especially in cases of minorities and women, as was found in NIST's 2024 report. Twenty organisations jointly under European Digital Rights called the practice a "systematic and invasive processing of young people's data" that risks discriminatory profiling.
Aggregation (linguistics)
In linguistics, aggregation is a subtask of natural language generation, which involves merging syntactic constituents (such as sentences and phrases) together. Sometimes aggregation can be done at a conceptual level. == Examples == A simple example of syntactic aggregation is merging the two sentences John went to the shop and John bought an apple into the single sentence John went to the shop and bought an apple. Syntactic aggregation can be much more complex than this. For example, aggregation can embed one of the constituents in the other; e.g., we can aggregate John went to the shop and The shop was closed into the sentence John went to the shop, which was closed. From a pragmatic perspective, aggregating sentences together often suggests to the reader that these sentences are related to each other. If this is not the case, the reader may be confused. For example, someone who reads John went to the shop and bought an apple may infer that the apple was bought in the shop; if this is not the case, then these sentences should not be aggregated. == Algorithms and issues == Aggregation algorithms must do two things: Decide when two constituents should be aggregated Decide how two constituents should be aggregated, and create the aggregated structure The first issue, deciding when to aggregate, is poorly understood. Aggegration decisions certainly depend on the semantic relations between the constituents, as mentioned above; they also depend on the genre (e.g., bureaucratic texts tend to be more aggregated than instruction manuals). They probably should depend on rhetorical and discourse structure. The literacy level of the reader is also probably important (poor readers need shorter sentences). But we have no integrated model which brings all these factors together into a single algorithm. With regard to the second issue, there have been some studies of different types of aggregation, and how they should be carried out. Harbusch and Kempen describe several syntactic aggregation strategies. In their terminology, John went to the shop and bought an apple is an example of forward conjunction Reduction Much less is known about conceptual aggregation. Di Eugenio et al. show how conceptual aggregation can be done in an intelligent tutoring system, and demonstrate that performing such aggregation makes the system more effective (and that conceptual aggregation make a bigger impact than syntactic aggregation). == Software == Unfortunately there is not much software available for performing aggregation. However the SimpleNLG system does include limited support for basic aggregation. For example, the following code causes SimpleNLG to print out The man is hungry and buys an apple.
Concurrency control
In information technology and computer science, especially in the fields of computer programming, operating systems, multiprocessors, and databases, concurrency control ensures that correct results for concurrent operations are generated, while getting those results as quickly as possible. Computer systems, both software and hardware, consist of modules, or components. Each component is designed to operate correctly, i.e., to obey or to meet certain consistency rules. When components that operate concurrently interact by messaging or by sharing accessed data (in memory or storage), a certain component's consistency may be violated by another component. The general area of concurrency control provides rules, methods, design methodologies, and theories to maintain the consistency of components operating concurrently while interacting, and thus the consistency and correctness of the whole system. Introducing concurrency control into a system means applying operation constraints which typically result in some performance reduction. Operation consistency and correctness should be achieved with as good as possible efficiency, without reducing performance below reasonable levels. Concurrency control can require significant additional complexity and overhead in a concurrent algorithm compared to the simpler sequential algorithm. For example, a failure in concurrency control can result in data corruption from torn read or write operations. == Concurrency control in databases == Comments: This section is applicable to all transactional systems, i.e., to all systems that use database transactions (atomic transactions; e.g., transactional objects in Systems management and in networks of smartphones which typically implement private, dedicated database systems), not only general-purpose database management systems (DBMSs). DBMSs need to deal also with concurrency control issues not typical just to database transactions but rather to operating systems in general. These issues (e.g., see Concurrency control in operating systems below) are out of the scope of this section. Concurrency control in Database management systems (DBMS; e.g., Bernstein et al. 1987, Weikum and Vossen 2001), other transactional objects, and related distributed applications (e.g., Grid computing and Cloud computing) ensures that database transactions are performed concurrently without violating the data integrity of the respective databases. Thus concurrency control is an essential element for correctness in any system where two database transactions or more, executed with time overlap, can access the same data, e.g., virtually in any general-purpose database system. Consequently, a vast body of related research has been accumulated since database systems emerged in the early 1970s. A well established concurrency control theory for database systems is outlined in the references mentioned above: serializability theory, which allows to effectively design and analyze concurrency control methods and mechanisms. An alternative theory for concurrency control of atomic transactions over abstract data types is presented in (Lynch et al. 1993), and not utilized below. This theory is more refined, complex, with a wider scope, and has been less utilized in the Database literature than the classical theory above. Each theory has its pros and cons, emphasis and insight. To some extent they are complementary, and their merging may be useful. To ensure correctness, a DBMS usually guarantees that only serializable transaction schedules are generated, unless serializability is intentionally relaxed to increase performance, but only in cases where application correctness is not harmed. For maintaining correctness in cases of failed (aborted) transactions (which can always happen for many reasons) schedules also need to have the recoverability (from abort) property. A DBMS also guarantees that no effect of committed transactions is lost, and no effect of aborted (rolled back) transactions remains in the related database. Overall transaction characterization is usually summarized by the ACID rules below. As databases have become distributed, or needed to cooperate in distributed environments (e.g., Federated databases in the early 1990, and Cloud computing currently), the effective distribution of concurrency control mechanisms has received special attention. === Database transaction and the ACID rules === The concept of a database transaction (or atomic transaction) has evolved in order to enable both a well understood database system behavior in a faulty environment where crashes can happen any time, and recovery from a crash to a well understood database state. A database transaction is a unit of work, typically encapsulating a number of operations over a database (e.g., reading a database object, writing, acquiring lock, etc.), an abstraction supported in database and also other systems. Each transaction has well defined boundaries in terms of which program/code executions are included in that transaction (determined by the transaction's programmer via special transaction commands). Every database transaction obeys the following rules (by support in the database system; i.e., a database system is designed to guarantee them for the transactions it runs): Atomicity - Either the effects of all or none of its operations remain ("all or nothing" semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible (atomic), and an aborted transaction does not affect the database at all. Either all the operations are done or none of them are. Consistency - Every transaction must leave the database in a consistent (correct) state, i.e., maintain the predetermined integrity rules of the database (constraints upon and among the database's objects). A transaction must transform a database from one consistent state to another consistent state (however, it is the responsibility of the transaction's programmer to make sure that the transaction itself is correct, i.e., performs correctly what it intends to perform (from the application's point of view) while the predefined integrity rules are enforced by the DBMS). Thus since a database can be normally changed only by transactions, all the database's states are consistent. Isolation - Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. Durability - Effects of successful (committed) transactions must persist through crashes (typically by recording the transaction's effects and its commit event in a non-volatile memory). The concept of atomic transaction has been extended during the years to what has become Business transactions which actually implement types of Workflow and are not atomic. However also such enhanced transactions typically utilize atomic transactions as components. === Why is concurrency control needed? === If transactions are executed serially, i.e., sequentially with no overlap in time, no transaction concurrency exists. However, if concurrent transactions with interleaving operations are allowed in an uncontrolled manner, some unexpected, undesirable results may occur, such as: The lost update problem: A second transaction writes a second value of a data-item (datum) on top of a first value written by a first concurrent transaction, and the first value is lost to other transactions running concurrently which need, by their precedence, to read the first value. The transactions that have read the wrong value end with incorrect results. The dirty read problem: Transactions read a value written by a transaction that has been later aborted. This value disappears from the database upon abort, and should not have been read by any transaction ("dirty read"). The reading transactions end with incorrect results. The incorrect summary problem: While one transaction takes a summary over the values of all the instances of a repeated data-item, a second transaction updates some instances of that data-item. The resulting summary does not reflect a correct result for any (usually needed for correctness) precedence order between the two transactions (if one is executed before the other), but rather some random result, depending on the timing of the updates, and whether certain update results have been included in the summary or not. Most high-performance transactional systems need to run transactions concurrently to meet their performance requirements. Thus, without concurrency control such systems can neither provide correct results nor maintain their databases consistently. === Concurrency control mechanisms === ==== Categories ==== The main categories of concurrency control mechanis
Inverse depth parametrization
In computer vision, the inverse depth parametrization is a parametrization used in methods for 3D reconstruction from multiple images such as simultaneous localization and mapping (SLAM). Given a point p {\displaystyle \mathbf {p} } in 3D space observed by a monocular pinhole camera from multiple views, the inverse depth parametrization of the point's position is a 6D vector that encodes the optical centre of the camera c 0 {\displaystyle \mathbf {c} _{0}} when in first observed the point, and the position of the point along the ray passing through p {\displaystyle \mathbf {p} } and c 0 {\displaystyle \mathbf {c} _{0}} . Inverse depth parametrization generally improves numerical stability and allows to represent points with zero parallax. Moreover, the error associated to the observation of the point's position can be modelled with a Gaussian distribution when expressed in inverse depth. This is an important property required to apply methods, such as Kalman filters, that assume normality of the measurement error distribution. The major drawback is the larger memory consumption, since the dimensionality of the point's representation is doubled. == Definition == Given 3D point p = ( x , y , z ) {\displaystyle \mathbf {p} =(x,y,z)} with world coordinates in a reference frame ( e 1 , e 2 , e 3 ) {\displaystyle (e_{1},e_{2},e_{3})} , observed from different views, the inverse depth parametrization y {\displaystyle \mathbf {y} } of p {\displaystyle \mathbf {p} } is given by: y = ( x 0 , y 0 , z 0 , θ , ϕ , ρ ) {\displaystyle \mathbf {y} =(x_{0},y_{0},z_{0},\theta ,\phi ,\rho )} where the first five components encode the camera pose in the first observation of the point, being c 0 = ( x 0 , y 0 , z 0 ) {\displaystyle \mathbf {c_{0}} =(x_{0},y_{0},z_{0})} the optical centre, ϕ {\displaystyle \phi } the azimuth, θ {\displaystyle \theta } the elevation angle, and ρ = 1 ‖ p − c 0 ‖ {\displaystyle \rho ={\frac {1}{\left\Vert \mathbf {p} -\mathbf {c} _{0}\right\Vert }}} the inverse depth of p {\displaystyle p} at the first observation.