Construction robots are a subset of industrial robots used for building and infrastructure construction on site, or in the production of materials and components offsite. A 2021 survey said 55% of construction companies in the United States, Europe, and China used robots in some form. This figure, however, reflects reported use across the construction value chain rather than widespread deployment of robots on active construction sites. Real-world adoption remains limited, with many robotic systems confined to pilot projects, controlled environments, or specific task applications rather than continuous on-site construction use. One of the main challenges in deploying robots on construction sites is the unstructured and variable nature of the environment, which differs fundamentally from controlled factory settings where industrial robots have traditionally operated. Some robots currently deployed on job sites assist with physically demanding or repetitive tasks: excavating, lifting heavy materials, surveying, laying out markers, tying rebar, and installing drywall. More advanced systems are being developed for exterior finishing, steel placement, masonry, and reinforced concrete work. In practice, rather than autonomous systems performing core building tasks, the most widely adopted robot applications on construction sites involve technologies such as aerial drones (or, less frequently, robot 'dogs' - for example, Boston Dynamics' Spot - or humanoid robots) used for surveying, inspection, and progress monitoring (the robots typically carry video and/or 360-degree cameras, LiDar scanners or other data capture devices, with data analysed using artificial intelligence and machine learning). Some emerging systems are designed as multifunctional construction robots, integrating multiple tools and capabilities within a single robotic platform to perform different stages of the construction process. These systems aim to improve operational flexibility and increase automation in complex construction environments. Experimental projects using robotic construction technologies and additive manufacturing have been demonstrated in several countries as part of broader efforts to industrialize the construction sector and improve productivity through automation and digitalization. == Features == Construction robots are generally required to meet the following criteria: Mobility: the ability to navigate around a construction site, including uneven terrain and confined spaces. Adaptability: the ability to handle components of variable size, weight, and shape. Environmental awareness: the ability to sense and respond to changing on-site conditions. Interactivity: the ability to operate alongside human workers and other equipment. Multitasking: the ability to perform several different operations within a single deployment. == Capabilities == Construction robots have been developed and tested for a range of on-site tasks, including: Progress monitoring — robots equipped with cameras and sensors can track construction progress and identify deviations from plans. Inspection — robots are used to investigate infrastructure at dangerous or inaccessible locations, reducing risk to human workers and eliminating human error. Wall construction — robotic systems can lay bricks and blocks with greater speed and consistency than manual labour. Earthmoving and material handling — autonomous excavators and haul trucks use GPS, lidar, and motion sensors to perform digging, trenching, and loading tasks with minimal human input. Grading and dozing — autonomous bulldozers use GPS, gyroscopes, and laser sensors to control blade angle and depth, improving surface finish accuracy and reducing material overuse. 3D printing — additive manufacturing systems can construct walls and structural elements directly from digital models. == Notable construction-related activities undertaken by robots == The distribution of robotic applications in construction varies across the project lifecycle. Most applications are concentrated in structural construction tasks such as masonry, concrete work, and assembly, while other phases, including planning, maintenance, and demolition, remain less represented. === Automated building systems === The Nisseki Yokohama Building (also known as Rail City Yokohama), a 30-storey office building in Yokohama, Japan, was constructed between 1994 and 1997 using the SMART system (Shimizu Manufacturing system by Advanced Robotics Technology), developed by Shimizu Corporation and a consortium of seven other Japanese companies. The system used automated horizontal hoists and vertical lifts to position steel beams, columns, precast concrete floor slabs, and prefabricated facade panels, with welding robots connecting structural elements under laser-guided precision. Each component was tracked by barcode to monitor progress and coordinate just-in-time delivery of materials. Obayashi Corporation developed the Advanced Building Construction System (ABCS), a similar automated platform used in several high-rise projects in Japan in the 1990s, including the NEC Head Office in Kanagawa (1997–2000). === Progress monitoring, inspection === Boston Dynamics' Spot was used in February 2024 to inspect sections of the M5 motorway in England for National Highways. A £15,000 humanoid robot (a G1 model from Chinese manufacturer Unitree) was deployed to capture 360-degree imagery and progress reports to support health and safety monitoring and reporting for UK contractor Tilbury Douglas in April 2026. In the US, Virginia Tech's ARCADE research lab is developing MARIO (Multi-Agent Robotic system for Inspection On-site), a heterogenous robotic system deploying multiple robots capable of different locomotion to perform remote real-time construction progress monitoring in complex construction sites. === Earthmoving === === Concrete works === Obayashi Corporation developed and deployed a robotic system for placing concrete layers in dam construction in Japan. A concrete floor finishing robot was deployed by Kajima and Tokimec in Japan. The MARK series were designed in 1984 to automate the levelling and trowelling of concrete slabs on construction sites, providing consistent finishing accuracy, improved efficiency, and reduced dependence on skilled labour === Masonry === SAM100 (Semi-Automated Mason), developed by Construction Robotics, is one of the first commercially available bricklaying robots for on-site masonry construction. In 2018, it was used in the construction of the University Arts Building at the University of Nevada, Reno — a $35.5 million facility — where it laid over 60,000 of the 100,000 bricks required, reducing the brick veneer installation time by approximately 50%. Hadrian X, developed by the Australian company Fastbrick Robotics, is a fully autonomous mobile bricklaying robot. In November 2022, it completed its first commercial project — five four-bedroom houses in Wellard, Western Australia. In February 2025, PulteGroup, one of the largest homebuilders in the United States, piloted Hadrian X on a site in Florida, constructing an entire house in a single day. === 3D printing === In May 2025, a residential building in Arinaga, Gran Canaria, Spain, was completed using 3D printing construction technology, as part of broader efforts to demonstrate robotic and additive manufacturing methods in the housing sector. In 2026, a three-storey apartment block in France was constructed using concrete 3D printing technology, three months faster than conventional building methods. Finland's Hyperion Robotics has opened a UK factory and used 3D printing with concrete to produce foundations for pipelines and for electricity substation bases, reducing time-consuming and weather-dependent onsite construction processes. == Social impact == The adoption of construction robots varies significantly by region and is shaped by labour market conditions, cultural attitudes, and regulatory frameworks. In Japan, construction robots have been embraced as a response to an ageing workforce and chronic labour shortages, and are generally viewed positively by the industry. In the United States, adoption has historically been slower, partly due to resistance from labour unions concerned about job displacement. Research suggests that the impact of automation on workers is uneven: while robots can create a productivity effect that benefits some workers, displacement effects are most pronounced among younger, less-educated workers in manufacturing-heavy regions. More than 60% of construction firms now report difficulty finding skilled operators, which has increased openness to automation as a practical solution to workforce shortages rather than a replacement for workers. In the UK, during onsite deployment of a humanoid robot for monitoring purposes, there were concerns that staff might think they were being watched ("It's not there to spy on people.... So, we insist that everyone is blurred out. N
EyeOS
eyeOS was a web desktop for cloud computing, whose main purpose is to enable collaboration and communication among users. It is mainly written in PHP, XML, and JavaScript. It is a private-cloud application platform with a web-based desktop interface. eyeOS delivers a whole desktop from the cloud with file management, personal management information tools, and collaborative tools, with the integration of the client's applications. == History == The first publicly available eyeOS version was released on August 1, 2005, as eyeOS 0.6.0 in Olesa de Montserrat, Barcelona (Spain). A worldwide community of developers soon took part in the project and helped improve it by translating, testing, and developing it. After two years of development, the eyeOS Team published eyeOS 1.0 on June 4, 2007. Compared with previous versions, eyeOS 1.0 introduced a complete reorganization of the code and some new web technologies, like eyeSoft, a portage-based web software installation system. Moreover, eyeOS also included the eyeOS Toolkit, a set of libraries allowing easy and fast development of new web applications. With the release of eyeOS 1.1 on July 2, 2007, eyeOS changed its license and migrated from GNU GPL Version 2 to Version 3. Version 1.2 was released just a month after the 1.1 version and integrated full compatibility with Microsoft Word files. eyeOS 1.5 Gala was released on January 15, 2008. This version was the first to support both Microsoft Office and OpenOffice.org file formats for documents, presentations, and spreadsheets. With this version, eyeOS also gained the ability to import and export documents in both formats using server-side scripting. eyeOS 1.6 was released on April 25, 2008, and included many improvements such as synchronization with local computers, drag and drop, a mobile version, and more. eyeOS 1.8 Lars was released on January 7, 2009, and featured a completely rewritten file manager and a new sound API to develop media-rich applications. Later, on April 1, 2009, 1.8.5 was released with a new default theme and some rewritten apps, such as the Word Processor and the Address Book. On July 13, 2009, 1.8.6 was released with an interface for the iPhone and a new version of eyeMail with support for POP3 and IMAP. eyeOS 1.9 was released on December 29, 2009. It was followed up with the 1.9.0.1 release with minor fixes on February 18, 2010. These releases were the last of the "classic desktop" interfaces. A major re-work was completed in March 2010, now called eyeOS 2.x. However, a small group of eyeOS developers still maintain the code within the eyeOS forum, where support is provided, but the eyeOS group itself has stopped active 1.x development. It is now available as the On-eye project on GitHub. Active development was halted on 1.x as of February 3, 2010. eyeOS 2.0 release took place on March 3, 2010. This was a total restructure of the operating system. The 2.x stable is the new series of eyeOS, which is in active development and will replace 1.x as stable in a few months. It includes live collaboration and more social capabilities than eyeOS 1.x. eyeOS then released 2.2.0.0 on July 28, 2010. On December 14, 2010, a working group inside the eyeOS open-source development community began the structure development and further upgrade of eyeOS 1.9.x. The group's main goal is to continue the work eyeOS has stopped on 1.9.x. eyeOS released 2.5 on May 17, 2011. This was the last release under an open source license. It is available on SourceForge for download under another project called eyeOS 2.5 Open Source Version. On April 1, 2014, Telefónica announced their acquisition of eyeOS. eyeOS would maintain its headquarters in the Catalonia, Spain, where their staff would continue to work but now as part of Telefónica. After its integration into Telefónica, eyeOS would continue to function as an independent subsidiary under CEO Michel Kisfaludi. == Structure and API == For developers, EyeOS provides the eyeOS Toolkit, a set of libraries and functions to develop applications for eyeOS. Using the integrated Portage-based eyeSoft system, one can create their own repository for eyeOS and distribute applications through it. Each core part of the desktop is its own application, using JavaScript to send server commands as the user interacts. As actions are performed using AJAX (such as launching an application), it sends event information to the server. The server then sends back tasks for the client to do in XML format, such as drawing a widget. On the server, eyeOS uses XML files to store information. This makes it simple for a user to set up on the server, as it requires zero configuration other than the account information for the first user, making it simple to deploy. To avoid bottlenecks that flat files present, each user's information and settings are stored in different files, preventing resource starvation from occurring, though this in turn may create issues in high volume user environments due to host operating system open file descriptor limits. == Professional edition == A Professional Edition of eyeOS was launched on September 15, 2011, as an operating system for businesses. It uses a new version number and was released under version 1.0 instead of continuing with the next version number in the open source project. The Professional Edition retains the web desktop interface used by the open source version while targeting enterprise users. A host of new features designed for enterprises, like file sharing and synchronization (called eyeSync), Active Directory/LDAP connectivity, system-wide administration controls, and a local file execution tool called eyeRun were introduced. A new suite of Web Apps (a mail client, calendar, instant messaging, and collaboration tools) was also introduced, specific to the enterprise edition for the web desktop. With eyeOS Professional Edition 1.1, a to-do task manager tool, Citrix XenApp integration, and a Facebook like 'wall' for collaboration were introduced. == Awards == 2007 – Received the Softpedia's Pick award. 2007 – Finalist at SourceForge's 2007 Community Choice Awards at the "Best Project" category. The winner for that category was 7-Zip. 2007 – Won the Yahoo! Spain Web Revelation award in the Technology category. 2008 – Finalist for the Webware 100 awards by CNET, under the "Browsing" category. 2008 – Finalist at the SourceForge's 2008 Community Choice Awards at the "Most Likely to Change the World" category. The winner for that category was Linux. 2009 – Selected Project of the Month (August 2009) by SourceForge. 2009 – BMW Innovation Award. 2010 – Winner of Accelera (Ernst & Young). 2010 – Asturias & Girona Spanish Prince award “IMPULSA”. 2011 – Winner of MIT's TR35 award as Innovator of the Year in Spain. == Community == eyeOS community is formed with the eyeOS forums, which reached 10,000 members on April 4, 2008; the eyeOS wiki; and the eyeOS Application Communities, available at the eyeOS-Apps website, hosted and provided by openDesktop.org as well as Softpedia.
CoDi
CoDi is a cellular automaton (CA) model for spiking neural networks (SNNs). CoDi is an acronym for Collect and Distribute, referring to the signals and spikes in a neural network. CoDi uses a von Neumann neighborhood modified for a three-dimensional space; each cell looks at the states of its six orthogonal neighbors and its own state. In a growth phase a neural network is grown in the CA-space based on an underlying chromosome. There are four types of cells: neuron body, axon, dendrite and blank. The growth phase is followed by a signaling- or processing-phase. Signals are distributed from the neuron bodies via their axon tree and collected from connection dendrites. These two basic interactions cover every case, and they can be expressed simply, using a small number of rules. == Cell interaction during signaling == The neuron body cells collect neural signals from the surrounding dendritic cells and apply an internally defined function to the collected data. In the CoDi model the neurons sum the incoming signal values and fire after a threshold is reached. This behavior of the neuron bodies can be modified easily to suit a given problem. The output of the neuron bodies is passed on to its surrounding axon cells. Axonal cells distribute data originating from the neuron body. Dendritic cells collect data and eventually pass it to the neuron body. These two types of cell-to-cell interaction cover all kinds of cell encounters. Every cell has a gate, which is interpreted differently depending on the type of the cell. A neuron cell uses this gate to store its orientation, i.e. the direction in which the axon is pointing. In an axon cell, the gate points to the neighbor from which the neural signals are received. An axon cell accepts input only from this neighbor, but makes its own output available to all its neighbors. In this way axon cells distribute information. The source of information is always a neuron cell. Dendritic cells collect information by accepting information from any neighbor. They give their output, (e.g. a Boolean OR operation on the binary inputs) only to the neighbor specified by their own gate. In this way, dendritic cells collect and sum neural signals, until the final sum of collected neural signals reaches the neuron cell. Each axonal and dendritic cell belongs to exactly one neuron cell. This configuration of the CA-space is guaranteed by the preceding growth phase. == Synapses == The CoDi model does not use explicit synapses, because dendrite cells that are in contact with an axonal trail (i.e. have an axon cell as neighbor) collect the neural signals directly from the axonal trail. This results from the behavior of axon cells, which distribute to every neighbor, and from the behavior of the dendrite cells, which collect from any neighbor. The strength of a neuron-neuron connection (a synapse) is represented by the number of their neighboring axon and dendrite cells. The exact structure of the network and the position of the axon-dendrite neighbor pairs determine the time delay and strength (weight) of a neuron-neuron connection. This principle infers that a single neuron-neuron connection can consist of several synapse with different time delays with independent weights. == Genetic encoding and growth of the network == The chromosome is initially distributed throughout the CA-space, so that every cell in the CA-space contains one instruction of the chromosome, i.e. one growth instruction, so that the chromosome belongs to the network as a whole. The distributed chromosome technique of the CoDi model makes maximum use of the available CA-space and enables the growth of any type of network connectivity. The local connection of the grown circuitry to its chromosome, allows local learning to be combined with the evolution of grown neural networks. Growth signals are passed to the direct neighbors of the neuron cell according to its chromosome information. The blank neighbors, which receive a neural growth signal, turn into either an axon cell or a dendrite cell. The growth signals include information containing the cell type of the cell that is to be grown from the signal. To decide in which directions axonal or dendritic trails should grow, the grown cells consult their chromosome information which encodes the growth instructions. These growth instructions can have an absolute or a relative directional encoding. An absolute encoding masks the six neighbors (i.e. directions) of a 3D cell with six bits. After a cell is grown, it accepts growth signals only from the direction from which it received its first signal. This reception direction information is stored in the gate position of each cell's state. == Implementation as a partitioned CA == The states of our CAs have two parts, which are treated in different ways. The first part of the cell-state contains the cell's type and activity level and the second part serves as an interface to the cell's neighborhood by containing the input signals from the neighbors. Characteristic of our CA is that only part of the state of a cell is passed to its neighbors, namely the signal and then only to those neighbors specified in the fixed part of the cell state. This CA is called partitioned, because the state is partitioned into two parts, the first being fixed and the second is variable for each cell. The advantage of this partitioning-technique is that the amount of information that defines the new state of a CA cell is kept to a minimum, due to its avoidance of redundant information exchange. == Implementation in hardware == Since CAs are only locally connected, they are ideal for implementation on purely parallel hardware. When designing the CoDi CA-based neural networks model, the objective was to implement them directly in hardware (FPGAs). Therefore, the CA was kept as simple as possible, by having a small number of bits to specify the state, keeping the CA rules few in number, and having few cellular neighbors. The CoDi model was implemented in the FPGA based CAM-Brain Machine (CBM) by Korkin. == History == CoDi was introduced by Gers et al. in 1998. A specialized parallel machine based on FPGA Hardware (CAM) to run the CoDi model on a large scale was developed by Korkin et al. De Garis conducted a series of experiments on the CAM-machine evaluating the CoDi model. The original model, where learning is based on evolutionary algorithms, has been augmented with a local learning rule via feedback from dendritic spikes by Schwarzer.
AgMES
The AgMES (Agricultural Metadata Element set) initiative was developed by the Food and Agriculture Organization (FAO) of the United Nations and aims to encompass issues of semantic standards in the domain of agriculture with respect to description, resource discovery, interoperability, and data exchange for different types of information resources. There are numerous other metadata schemas for different types of information resources. The following list contains a list of a few examples: Document-like Information Objects (DLIOs): Dublin Core, Agricultural Metadata Element Set (AgMES) Events: VCalendar Geographic and Regional Information: Geographic information—Metadata ISO/IEC 11179 Standards Persons: Friend-of-a-friend (FOAF), vCard Plant Production and Protection: Darwin Core (1.0 and 2.0) (DwC) AgMES as a namespace is designed to include agriculture specific extensions for terms and refinements from established standard metadata namespaces like Dublin Core, AGLS etc. Thus, to be used for Document-like Information Objects, for example like publications, articles, books, web sites, papers, etc., it will have to be used in conjunction with the standard namespaces mentioned before. The AgMES initiative strives to achieve improved interoperability between information resources in agricultural domain by enabling means for exchange of information. Describing a DLIO with AgMES means exposing its major characteristics and contents in a standard way that can be reused easily in any information system. The more institutions and organizations in the agricultural domain that use AgMES to describe their DLIOs, the easier it will be to interchange data in between information systems like digital libraries and other repositories of agricultural information. == Use of AgMES == Metadata on agricultural Document-like Information Objects (DLIOs) can be created and stored in various formats: embedded in a web site (in the manner as with the HTML meta tag) in a separate metadata database in an XML file in an RDF file AgMES defines elements that can be used to describe a DLIO that can be used together with other metadata standards such as the Dublin Core, the Australian Government Locator Service. A complete list of all elements, refinements and schemes endorsed by AgMES is available from the AgMES website. === Creating application profiles === Application profiles are defined as schemas which consist of data elements drawn from one or more namespaces, combined by implementers, and optimized for a particular local application. Application profiles share the following four characteristics: They draw upon existing pool of metadata definition standards to extract suitable application- or requirement oriented elements. An application profile cannot create new elements. Application profiles specify the application specific details such as the schemes or controlled vocabularies. An application profile also contains information such as the format for the element value, cardinality or data type. Lastly, an application profile can refine standardized definitions as long as it is "semantically narrower or more specific". This capability of application profiles caters to situations where a domain specific terminology is needed to replace a more general one. === Sample application profiles using AgMES === The AGRIS Application Profile is a standard created specifically to enhance the description, exchange and subsequent retrieval of agricultural Document-like Information Objects (DLIOs). It is a format that allows sharing of information across dispersed bibliographic systems and is based on well-known and accepted metadata standards. The Event Application Profile is a standard created to allow members of the Agricultural community to 'know' about an upcoming event and guide them to the event Web site where they can find further information. The information communicated is thus minimum yet interoperable across domains and organizations. == AgMES and the semantic web == One of the advantages of the AgMES metadata schema is the ability to link between the metadata element and controlled vocabularies. The use of controlled vocabulary provides a "known" set of options to the indexer (and the search programmer) as to how the field can be filled out. Often the values may come from a specific thesaurus (e.g. AGROVOC) or classification schemes (e.g. the AGRIS/CARIS classification scheme) etc. Thanks to the possibility to use controlled vocabularies for metadata elements, the user is provided with the most precise information. In this context, work is also being carried out on exploiting the power of controlled vocabularies expressed as using URIs and machine-understandable semantics. In this context, FAO is promoting the Agricultural Ontology Service (AOS) initiative with the objective of expressing more semantics within the traditional thesaurus AGROVOC and build a Concept Server as a repository from which it will be always possible to extract traditional KOS.
Cognitive tutor
A cognitive tutor is a particular kind of intelligent tutoring system that utilizes a cognitive model to provide feedback to students as they are working through problems. This feedback will immediately inform students of the correctness, or incorrectness, of their actions in the tutor interface; however, cognitive tutors also have the ability to provide context-sensitive hints and instruction to guide students towards reasonable next steps. == Introduction == The name of Cognitive Tutor now usually refers to a particular type of intelligent tutoring system produced by Carnegie Learning for high school mathematics based on John Anderson's ACT-R theory of human cognition. However, cognitive tutors were originally developed to test ACT-R theory for research purposes since the early 1980s and they are developed also for other areas and subjects such as computer programming and science. Cognitive Tutors can be implemented into classrooms as a part of blended learning that combines textbook and software activities. The Cognitive Tutor programs utilize cognitive model and are based on model tracing and knowledge tracing. Model tracing means that the cognitive tutor checks every action performed by students such as entering a value or clicking a button, while knowledge tracing is used to calculate the required skills students learned by measuring them on a bar chart called Skillometer. Model tracing and knowledge tracing are essentially used to monitor students' learning progress, guide students to correct path to problem solving, and provide feedback. The Institute of Education Sciences published several reports regarding the effectiveness of Carnegie Cognitive Tutor. A 2013 report concluded that Carnegie Learning Curricula and Cognitive Tutor was found to have mixed effects on mathematics achievement for high school students. The report identified 27 studies that investigate the effectiveness of Cognitive Tutor, and the conclusion is based on 6 studies that meet What Works Clearinghouse standards. Among the 6 studies included, 5 of them show intermediate to significant positive effect, while 1 study shows statistically significant negative effect. Another report published by Institute of Education Sciences in 2009 found that Cognitive Tutor Algebra I to have potentially positive effects on math achievement based on only 1 study out of 14 studies that meets What Works Clearinghouse standards. It should be understood that What Works Clearinghouse standards call for relatively large numbers of participants, true random assignments to groups, and for a control group receiving either no treatment or a different treatment. Such experimental conditions are difficult to meet in schools, and thus only a small percentage of studies in education meet the standards of this clearinghouse, even though they may still be of value. == Theoretical foundations == === Four-component architecture === Intelligent tutoring systems (ITS) have a four-component architecture: a domain model, a student model, a tutoring model and an interface component. The domain model contains the rules, concepts, and knowledge related to the domain to be learned. It helps to evaluate students' performance and detect students' errors by setting a standard of domain expertise. The student model, the central component of an ITS, is expected to contain knowledge about the students: their cognitive and affective states, and their progress as they learn. The function of the student model is threefold: to gather data from and about the learner, to represent the learner's knowledge and learning process, and to perform diagnostics of a student's knowledge and select optimal pedagogical strategies. The tutoring model uses the data gained from the domain model and student model to make decisions about tutoring strategies such as whether or not to intervene, or when and how to intervene. Functions of the tutoring model include instruction delivery and content planning. The interface component reflects the decisions made by the tutoring model in different forms such as Socratic dialogs, feedback and hints. Students interact with the tutor through the learning interface, also known as communication. The interface provides domain knowledge elements. === Cognitive model === A cognitive model replicates the domain knowledge and skills comparable to that of a human expert or an advanced student of the domain. A cognitive model enables intelligent tutoring systems to respond to problem-solving situations in a way similar to a human tutor. A tutoring system adopting a cognitive model is called a cognitive tutor. A cognitive model is an expert system that generates a multitude of solutions to the problems presented to students. The cognitive model is used to trace each student's solution through complex alternative solution paths, enabling the tutor to provide step-by-step feedback and advice, and to maintain a targeted model of the student's knowledge based on student performance. === Cognitive Tutors === Cognitive Tutors provide step-by-step guidance as a learner develops a complex problem-solving skill through practice. Typically, cognitive tutors provide such forms of support as: (a) a problem-solving environment that is designed rich and "thinking visible"; (b) step-by-step feedback on student performance; (c) feedback messages specific to errors; (d) context-specific next-step hints at student's request, and (e) individualized problem selection. Cognitive Tutors accomplish two of the principal tasks characteristic of human tutoring: (1) monitors the student's performance and providing context-specific individual instruction, and (2) monitors the student's learning and selects appropriate problem-solving activities. Both cognitive model and two underlying algorithms, model tracing and knowledge tracing, are used to monitor the student's learning. In model tracing, the cognitive tutor uses the cognitive model in complex problems to follow the student's individual path and provide prompt accuracy feedback and context-specific advice. In knowledge tracing, the cognitive tutor uses a Bayesian Knowledge Tracing method of evaluating the student's knowledge and uses this student model to select appropriate problems for each student. === Cognitive architecture === Cognitive tutor development is guided by ACT-R cognitive architecture, which specifies the underlying framework developing the cognitive model or expert component of a cognitive tutor. ACT-R, a member of the ACT family, is the most recent cognitive architecture, devoted primarily to modelling human behavior. ACT-R includes a declarative memory of factual knowledge and a procedural memory of production rules. The architecture functions by matching productions on perceptions and facts, mediated by the real-valued activation levels of objects, and executing them to affect the environment or alter declarative memory. ACT-R has been used to model psychological aspects such as memory, attention, reasoning, problem solving, and language processing. == Application and utilization == The first real world applications of cognitive tutors were in the 1980s and involved a geometry proof tutor used by high school students and a LISP programming tutor used by college students in a mini course in introductory programming course at Carnegie Mellon University. Since then, cognitive tutors have been used in a variety of scenarios, with a few organizations developing their own cognitive tutor programs. These programs have been used with students spanning elementary school through university level, though primarily in the subject areas of Computer Programming, Mathematics, and Science. One of the first organizations to develop a system for use within the school system was the PACT Center at Carnegie Mellon University. Their aim was to "...develop systems that provide individualized assistance to students as they work on challenging real-world problems in complex domains such as computer programming, algebra and geometry". PACT's most successful product was the Cognitive Tutor Algebra course. Originally created in the early 1990s, this course was in use in 75 schools through the U.S. by 1999, and then its spin-off company, Carnegie Learning, now offers tutors to thousands of schools in the U.S. The Carnegie Mellon Cognitive Tutor has been shown to raise students' math test scores in high school and middle-school classrooms, and their Algebra course was designated one of five exemplary curricula for K-12 mathematics educated by the US Department of Education. There were several research projects conducted by the PACT Center to utilize Cognitive tutor for courses in Excel and to develop an intelligent tutoring system for algebra expression writing, called Ms. Lindquist. Further, in 2005, Carnegie Learning released Bridge to Algebra, a product intended for middle schools that was piloted in over 100 schools. Cognitive tutoring software is continuing to be used.
ElabFTW
eLabFTW is a web application written by Nicolas Carpi in PHP which can be used to create personal and common logbooks. It has been developed at the Curie Institute originally. Besides there, it is used on universities around the world eLabFTW is licensed under the GNU Affero General Public License as free software. It is translated into seven languages. == Description == eLabFTW is a free and open-source lab book. It is written in PHP and uses a MySQL database. Docker containers are also available. Among the various features are Secure. Entries and transmission are encrypted Timestamps. RFC 3161 compliant timestamping of experiments. Inventory management. Apart from experience logs, it also can manage the inventory Import and export. Entries can be imported and exported == Platforms == eLabFTW is a PHP package with Mysql database. Therefore, it can be executed on most servers. Furthermore, the docker containers allow to run it almost everywhere. == Usage == eLabFTW is used by various universities, like University of Alberta, Berkeley University, Hanover Medical School, Cardiff University and UMC Utrecht
Artificial intelligence systems integration
The core idea of artificial intelligence systems integration is making individual software components, such as speech synthesizers, interoperable with other components, such as common sense knowledgebases, in order to create larger, broader and more capable A.I. systems. The main methods that have been proposed for integration are message routing, or communication protocols that the software components use to communicate with each other, often through a middleware blackboard system. Most artificial intelligence systems involve some sort of integrated technologies, for example, the integration of speech synthesis technologies with that of speech recognition. However, in recent years, there has been an increasing discussion on the importance of systems integration as a field in its own right. Proponents of this approach are researchers such as Marvin Minsky, Aaron Sloman, Deb Roy, Kristinn R. Thórisson and Michael A. Arbib. A reason for the recent attention A.I. integration is attracting is that there have already been created a number of (relatively) simple A.I. systems for specific problem domains (such as computer vision, speech synthesis, etc.), and that integrating what's already available is a more logical approach to broader A.I. than building monolithic systems from scratch. == Integration focus == The focus on systems' integration, especially with regard to modular approaches, derive from the fact that most intelligences of significant scales are composed of a multitude of processes and/or utilize multi-modal input and output. For example, a humanoid-type of intelligence would preferably have to be able to talk using speech synthesis, hear using speech recognition, understand using a logical (or some other undefined) mechanism, and so forth. In order to produce artificially intelligent software of broader intelligence, integration of these modalities is necessary. == Challenges and solutions == Collaboration is an integral part of software development as evidenced by the size of software companies and the size of their software departments. Among the tools to ease software collaboration are various procedures and standards that developers can follow to ensure quality, reliability and that their software is compatible with software created by others (such as W3C standards for webpage development). However, collaboration in fields of A.I. has been lacking, for the most part not seen outside the respected schools, departments or research institutes (and sometimes not within them either). This presents practitioners of A.I. systems integration with a substantial problem and often causes A.I. researchers to have to 're-invent the wheel' each time they want a specific functionality to work with their software. Even more damaging is the "not invented here" syndrome, which manifests itself in a strong reluctance of A.I. researchers to build on the work of others. The outcome of this in A.I. is a large set of "solution islands": A.I. research has produced numerous isolated software components and mechanisms that deal with various parts of intelligence separately. To take some examples: Speech synthesis FreeTTS from CMU Speech recognition Sphinx from CMU Logical reasoning OpenCyc from Cycorp Open Mind Common Sense Net from MIT With the increased popularity of the free software movement, a lot of the software being created, including A.I. systems, is available for public exploit. The next natural step is to merge these individual software components into coherent, intelligent systems of a broader nature. As a multitude of components (that often serve the same purpose) have already been created by the community, the most accessible way of integration is giving each of these components an easy way to communicate with each other. By doing so, each component by itself becomes a module, which can then be tried in various settings and configurations of larger architectures. Some challenging and limitations of using A.I. software is the uncontrolled fatal errors. For example, serious and fatal errors have been discovered in very precise fields such as human oncology, as in an article published in the journal Oral Oncology Reports entitled "When AI goes wrong: Fatal errors in oncological research reviewing assistance". The article pointed out a grave error in artificial intelligence based on GBT in the field of biophysics. Many online communities for A.I. developers exist where tutorials, examples, and forums aim at helping both beginners and experts build intelligent systems. However, few communities have succeeded in making a certain standard, or a code of conduct popular to allow the large collection of miscellaneous systems to be integrated with ease. == Methodologies == === Constructionist design methodology === The constructionist design methodology (CDM, or 'Constructionist A.I.') is a formal methodology proposed in 2004, for use in the development of cognitive robotics, communicative humanoids and broad AI systems. The creation of such systems requires the integration of a large number of functionalities that must be carefully coordinated to achieve coherent system behavior. CDM is based on iterative design steps that lead to the creation of a network of named interacting modules, communicating via explicitly typed streams and discrete messages. The OpenAIR message protocol (see below) was inspired by the CDM and has frequently been used to aid in the development of intelligent systems using CDM. == Examples == ASIMO, Honda's humanoid robot, and QRIO, Sony's version of a humanoid robot. Cog, M.I.T. humanoid robot project under the direction of Rodney Brooks. AIBO, Sony's robot dog, integrates vision, hearing and motorskills. TOPIO, TOSY's humanoid robot can play ping-pong with human