Robotics is the interdisciplinary study and practice of the design, construction, operation, and use of robots. A roboticist is someone who specializes in robotics. Robotics usually combines four aspects of design work: a power source (e.g. a battery), mechanical construction, a control system (electrical circuits), and software (run by remote control or artificial intelligence). The goal of most robotics is to design machines that can assist humans in various fields, such as agriculture, construction, domestic work, food processing, inventory management, manufacturing, medicine, military, mining, space exploration, and transportation. Robots impact humans by displacing workers. Some expect this to occur at an increasing rate, leading to proposed solutions such as basic income. Robotics is itself a lucrative business that creates careers, especially for postgraduates. Roboticists often aim to create machines that seem to interface naturally with humans. The field is under active research and development, with areas of interest including robot kinematics and quantum robotics. == Design == Robotics usually combines four aspects of design work to create a robot: Power source: Potential energy sources include wired electricity, a battery, and/or petrol. Mechanical construction: A physical form or combination of forms is designed to functionally achieve tasks within a given range of environments. This can include locomotive elements such as wheels and caterpillar tracks, as well as hydraulic limbs and manipulators (e.g. hands). Control system: Electrical circuits (utilizing components such as diodes and transistors) are used to run software, govern motor movement, and read sensors. Software: A program is how a robot decides when or how to do something. Robotic programs can be run by remote control, artificial intelligence (AI), or a hybrid of the two. AI programming is an important part of robotic navigation and human–robot interaction. === Power source === Many different types of batteries can be used as a power source. Most are lead–acid batteries, which are safe and have relatively long shelf lives but are rather heavy compared to silver–cadmium batteries, which are much smaller in volume and much more expensive. Designing a battery-powered robot needs to take into account factors such as safety, cycle lifetime, and weight. Generators, often some type of internal combustion engine, can also be used, but are often mechanically complex and inefficient. Additionally, a tether could connect the robot to a power supply, saving weight and space, but requiring a cumbersome cable. Potential power sources include: Flywheel energy storage Hydraulics Nuclear Organic garbage (through anaerobic digestion) Pneumatics (compressed gases) Solar power === Mechanical construction === Actuators are the "muscles" of a robot, the parts which convert stored energy into movement. The most popular actuators are electric motors that rotate a wheel or gear and linear actuators that control factory robots. Most robots use electric motors—often brushed and brushless DC motors in portable robots or AC motors in industrial robots and computer numerical control machines—especially in systems with lighter loads and where the predominant form of motion is rotational. Meanwhile, linear actuators move in and out and often have quicker direction changes, particularly when large forces are needed, such as with industrial robotics. They are typically powered by oil or compressed air, but can also be powered by electricity, usually via a motor and a leadscrew. The mechanical rack and pinion is common. Recent alternatives to DC motors are piezoelectric motors, including ultrasonic motors, in which tiny piezoceramic elements vibrate many thousands of times per second, causing linear or rotary motion. One type uses the vibration of the piezo elements to step the motor in a circle or a straight line; another type uses the piezo elements to vibrate a nut or drive a screw. The advantages of these motors are nanometer resolution, speed, and force for their size. Series elastic actuation (SEA) relies on introducing intentional elasticity between the motor actuator and the load for robust force control. Due to the resultant lower reflected inertia, series elastic actuation improves safety during robot interactions or collisions. Further, it provides energy efficiency and shock absorption (mechanical filtering) while reducing excessive wear on the transmission and other components. This approach has successfully been employed in various robots, particularly advanced manufacturing robots and walking humanoid robots. The controller design of a series elastic actuator is most often performed within the passivity framework as it ensures the safety of interaction with unstructured environments. However, this framework suffers from stringent limitations imposed on the controller, which may impact performance. Pneumatic artificial muscles, also known as air muscles, are special tubes that expand (typically up to 42%) when air is forced inside them; they are used in some robot applications. Muscle wire, also known as shape memory alloy, is a material that contracts (under 5%) when electricity is applied; they have been used for some small robots. Electroactive polymers are a plastic material that can contract substantially (up to 380% activation strain) from electricity and have been used in the facial muscles and arms of humanoid robots, as well as to enable new robots to float, fly, swim or walk. Additionally, elastic carbon nanotubes are a promising experimental artificial muscle technology. The absence of defects in carbon nanotubes enables these filaments to deform elastically by several percent, with energy storage levels of perhaps 10 J/cm3 for metal nanotubes. Human biceps could be replaced with wire of this material measuring 8 millimetres (3⁄8 in) in diameter, feasibly allowing future robots to outperform humans. ==== Locomotion ==== Robots with only one or two wheel(s) can have advantages such as greater efficiency, reduced parts, and navigation through confined areas. A one-wheeled robot balances on a round ball; Carnegie Mellon University's Ballbot is the approximate height and width of a person. Several attempts have also been made to build spherical robots (also known as orb bots or ball bots), which move by spinning a weight inside the ball or rotating outer shells. Two-wheeled balancing robots generally use a gyroscope to detect how much a robot is falling and drive the wheels proportionally up to hundreds of times per second to counterbalance the fall, based on inverted pendulum dynamics. NASA's Robonaut has been mounted to a Segway for a similar effect. Most mobile robots have four wheels or continuous tracks. Six wheels can give better traction in outdoor terrain, while tracks provide even more grip. Tracked wheels are common for outdoor off-road robots, but are difficult to use indoors. A small number of skating robots have been developed, one of which is a multimodal walking and skating device with four legs and unpowered wheels. Several robots have been made that can walk on two legs, but not yet as reliably as a human. Many other robots have been built that walk on more than two legs, being significantly easier. Walking robots could be used for uneven terrains, providing a high degree of mobility and efficiency, but two-legged robots can currently only handle flat floors or perhaps stairs. Some approaches have included: The zero moment point (ZMP) is the algorithm used by robots such as Honda's ASIMO. The robot's onboard computer tries to keep the total inertial forces (the combination of Earth's gravity and the acceleration and deceleration of walking) exactly opposed by the floor reaction force (the force of the floor pushing back on the robot's foot). In this way, the two forces cancel out, leaving no moment (force causing the robot to rotate and fall over). Human observers note that this is not exactly how a human walks, with some describing ASIMO's walk as looking like it needs use the bathroom. ASIMO's walking algorithm utilizes some dynamic balancing, but requires a flat surface. Several robots, built in the 1980s by Marc Raibert at the MIT Leg Laboratory, successfully demonstrated very dynamic walking. Initially, a robot with only one leg, and a very small foot could stay upright simply by hopping. The movement is the same as that of a person on a pogo stick. As the robot falls to one side, it would jump slightly in that direction to catch itself. Soon, the algorithm was generalized to two and four legs. A bipedal robot was demonstrated running and even performing somersaults. A quadruped was also demonstrated which could trot, run, pace, and bound. A more advanced approach is a dynamic balancing algorithm, which constantly monitors the robot's motion and places the feet to maintain stability. This technique has been demonstrated by Anybots' Dexter robot (
Avid DS
Avid DS (which was called Avid DS Nitris until early 2008) is a high-end offline and finishing system comprising a non-linear editing system and visual effects software. It was developed by Softimage (this company was owned by Microsoft at the time of DS v1.0's launch before being acquired from Microsoft by Avid Technology, Inc. shortly thereafter) in Montreal. DS was discontinued on September 30, 2013 with support ending on the same date the following year. == Software == DS was called ‘Digital Studio’ in development. It was envisioned to be a complete platform for video/audio work. The first previews of the system were on the SGI platform, but this version was never released. The system was rewritten on Windows NT with different video hardware platforms (Matrox DigiSuite or Play Trinity running on a NetPower system) before the final system was released on Intergraph/StudioZ hardware in January 1998. After its acquisition by Avid, DS was always positioned as a high end video finishing tool. However, many users found it to be uniquely soup-to-nuts in its capabilities. From version 1.0 of the product, it competed with products like Autodesk Smoke, Quantel and Avid Symphony. The toolset in DS offered video timeline editing, an object-oriented vector-based paint tool, 2D layer compositing, sample based audio and starting with version 3.01 of the product, a 3D environment. Originally, a subset of the Softimage|XSI 3D software was planned to become part of the DS toolset, both were built on the same software foundation, but over time the code bases divided between the applications and the integration never happened. While the first version of the DS still lacked a few key features (no 3D, poor keying, no real-time effects), it had some significant features compared to the competing products at the time. It offered a large number of built in effects. Avid OMF import was available, positioning Softimage DS as a strong finishing tool for then typical off-line Avid systems. Lastly the integration of the toolset of Softimage DS was beyond what other product offered. A Softimage DS user could quickly go from editing, to paint, to compositing with a few mouse clicks all inside the same interface. Some of the lacking features were quickly resolved, within months of version 1.0 a new chroma keyer was released. Early versions of the software (up thru 4.0) added additional key features. Development continued with one of the first uncompressed HD editing systems (version 4.01) and an attempt to make the system more friendly to Media Composer editors in version 6. In later versions (v7.5 on beyond) DS was criticized for slow development of compositing tools, mainly lack of a new 3D environment and better tracking tools. Many DS users felt that Avid had not been giving DS the attention that it deserved. On July 7, 2013, Avid sent out an email marking the end of life of the DS product. "To Our Avid DS customers, We are writing to inform you that Avid will be realigning our business strategy to focus on a core suite of products to best leverage our developmental and creative resources. As part of this transition, we will be ceasing future development of Avid DS with a final sale date of September 30th, 2013" == Hardware == Up until version 10.5, DS was sold as a turn-key system; the software was not available without purchasing CPU, I/O and storage hardware from Avid. Beginning with 10.5, customers were able to configure their own systems using widely available components, based on recommended system requirements. In turn-key systems, there were many hardware refreshes over time. StudioZ single stream: Intergraph TDZ-425 with 30 minutes of uncompressed SCSI storage. CPUs at the time were Pentium II/300 MHz. StudioZ dual stream: Intergraph TDZ-2000 GT1 with one hour of fibre channel storage. CPUs on first systems were Pentium II/400 MHz, but last shipping systems had Pentium III/1 GHz. DS was one of the first applications to show that real-time effects could be processed with just the CPUs of the system, not requiring special video cards with real-time effect hardware. Equinox: Developed by Avid, it was one of the first uncompressed HD video cards available. Systems were available on CPUs from Pentium III/1 GHz to Pentium 4/2.8 GHz. Storage was typically SCSI, but fibre channel was also supported. Nitris DNA: Developed by Avid, the Nitris hardware was probably the largest hardware update to the system since it was released. 10-bit HD and SD support was standard. Real-time down and cross convert. This was the only hardware for DS that had on-board effect processing. This allowed a system at the time to play back dual-stream uncompressed HD effects in real-time at 16-bit precision. This was also the first hardware from Avid to support the DNxHD codec. Starting with Pentium 4, Intel Core Xeons were supported. SCSI storage was primarily used. AJA Video Systems: First available as a 4:4:4 option to be used in conjunction with Nitris hardware. Final-generation DS systems used the AJA Video Systems Kona 3 (Xena 2K) card as the only I/O for the system. The last systems shipped with two Intel Core Xeon 6-core processors. SAS is the recommended storage for these systems. == History ==
Jakub Pachocki
Jakub Pachocki (born 1991) is a Polish computer scientist and former competitive programmer. He is best known as OpenAI's chief scientist and for his role in overseeing development of GPT-4. == Background == Pachocki was born in 1991 in Gdańsk, Poland. In high school, he was a six-time finalist of the Polish Olympiad in Informatics. In 2009, he qualified for the International Olympiad in Informatics, winning a silver medal. Pachocki obtained his undergraduate degree in Computer Science from the University of Warsaw. He represented his university at the International Collegiate Programming Contest with his team winning a gold medal and coming second place overall in 2012. In the same year he was also the champion of the Google Code Jam. From 2011 to 2012, Pachocki worked at Facebook as a software engineering intern. Pachocki attended graduate school at Carnegie Mellon University, where he obtained his PhD under the supervision of Gary Miller. == Career == After graduation, Pachocki did postdoc work at Harvard University and Simons Institute for the Theory of Computing. === OpenAI === In 2017, Pachocki joined OpenAI. In 2021, he became OpenAI's research director where he led the development of GPT-4 and OpenAI Five. In May 2024, he became chief scientist after his mentor Ilya Sutskever left the company. OpenAI CEO Sam Altman has called Pachocki "easily one of the greatest minds of our generation". == Competitive programming achievements == International Olympiad in Informatics: Silver medal (2009) International Collegiate Programming Contest World Finals: Gold medal (second place overall in 2012) Google Code Jam: Champion (2012), Third place (2011) Facebook Hacker Cup: Second place (2013) TopCoder Open Algorithm: Second place (2012) A more comprehensive list of achievements can be found at the Competitive Programming Hall Of Fame website.
Composite Capability/Preference Profiles
Composite Capability/Preference Profiles (CC/PP) is a specification for defining capabilities and preferences of user agents (also known as "delivery context"). The delivery context can be used to guide the process of tailoring content for a user agent. CC/PP is a vocabulary extension of the Resource Description Framework (RDF). The CC/PP specification is maintained by the W3C's Ubiquitous Web Applications Working Group (UWAWG) Working Group. == History == Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0 became a W3C recommendation on 15 January 2004. A "Last-Call Working-Draft" of CC/PP 2.0 was issued in April 2007
Social History and Industrial Classification
Social History and Industrial Classification (SHIC) is a classification system used by many British museums for social history and industrial collections. It was first published in 1983. == Purpose == SHIC classifies materials (books, objects, recordings etc.) by their interaction with the people who used them. For example, a carpenter's hammer is classified with other tools of the carpenter, and not with a blacksmith's hammer. In contrast other classification systems, for example the Dewey Decimal Classification, might class all hammers together and close to the classification for other percussive tools. The specialist subject network, Social History Curator's Group (SHCG), obtained funding in 2012 to develop an on-line version, now on their website http://www.shcg.org.uk/ == Scheme == Materials are classified under four major category numbers: Community life Domestic and family life Personal life Working life Further classification within a category is by the use of further numbers after the decimal point. It is permissible to assign more than one classification in cases where the object had more than one use.
Control-flow integrity
Control-flow integrity (CFI) is a general term for computer security techniques that prevent a wide variety of malware attacks from redirecting the flow of execution (the control flow) of a program. == Background == A computer program commonly changes its control flow to make decisions and use different parts of the code. Such transfers may be direct, in that the target address is written in the code itself, or indirect, in that the target address itself is a variable in memory or a CPU register. In a typical function call, the program performs a direct call, but returns to the caller function using the stack – an indirect backward-edge transfer. When a function pointer is called, such as from a virtual table, we say there is an indirect forward-edge transfer. Attackers seek to inject code into a program to make use of its privileges or to extract data from its memory space. Before executable code was commonly made read-only, an attacker could arbitrarily change the code as it is run, targeting direct transfers or even do with no transfers at all. After W^X became widespread, an attacker wants to instead redirect execution to a separate, unprotected area containing the code to be run, making use of indirect transfers: one could overwrite the virtual table for a forward-edge attack or change the call stack for a backward-edge attack (return-oriented programming). CFI is designed to protect indirect transfers from going to unintended locations. == Techniques == Associated techniques include code-pointer separation (CPS), code-pointer integrity (CPI), stack canaries, shadow stacks (SS), and vtable pointer verification. These protections can be classified into either coarse-grained or fine-grained based on the number of targets restricted. A coarse-grained forward-edge CFI implementation, could, for example, restrict the set of indirect call targets to any function that may be indirectly called in the program, while a fine-grained one would restrict each indirect call site to functions that have the same type as the function to be called. Similarly, for a backward edge scheme protecting returns, a coarse-grained implementation would only allow the procedure to return to a function of the same type (of which there could be many, especially for common prototypes), while a fine-grained one would enforce precise return matching (so it can return only to the function that called it). == Implementations == Related implementations are available in Clang (LLVM front-end),, GNU Compiler Collection, Microsoft's Control Flow Guard and Return Flow Guard, Google's Indirect Function-Call Checks and Reuse Attack Protector (RAP). === LLVM/Clang === The LLVM compiler's C/C++ front-end Clang provides a number of "CFI" schemes that works on the forward edge by checking for errors in virtual tables and type casts. Not all of the schemes are supported on all platforms and most of them, the exception being two "kcfi" schemes intended for low-level kernel software, depends on link-time optimization (LTO) to know what functions are supposed to be called in normal cases. Also provided is a separate "shadow call stack" (SCS) instrumentation pass that defends on the backward edge by checking for call stack modifications, available only for the aarch64 and RISC-V ISAs. And due to use of a shared processor register SCS is only enforceable on certain ABIs or if in other ways it is ensured that any other software using the register set (thread/processor) does not interfere with this use. Google has shipped Android with the Linux kernel compiled by Clang with link-time optimization (LTO) and CFI enabled since 2018. Even though SCS is available for the Linux kernel as an option, and support is also available for Android's system components it is recommended only to enable it for components for which it can be ensured that no third party code is loaded. === GCC === The GNU Compiler Collection implemented a "shadow call stack" compatible with Clang for aarch64 in v12 released in 2022. This feature is primarily intended for building the Linux kernel as support is missing from GCC user space libraries. === Intel Control-flow Enforcement Technology === Intel Control-flow Enforcement Technology (CET) detects compromises to control flow integrity with a shadow stack (SS) and indirect branch tracking (IBT). The kernel must map a region of memory for the shadow stack not writable to user space programs except by special instructions. The shadow stack stores a copy of the return address of each CALL. On a RET, the processor checks if the return address stored in the normal stack and shadow stack are equal. If the addresses are not equal, the processor generates an INT #21 (Control Flow Protection Fault). Indirect branch tracking detects indirect JMP or CALL instructions to unauthorized targets. It is implemented by adding a new internal state machine in the processor. The behavior of indirect JMP and CALL instructions is changed so that they switch the state machine from IDLE to WAIT_FOR_ENDBRANCH. In the WAIT_FOR_ENDBRANCH state, the next instruction to be executed is required to be the new ENDBRANCH instruction (ENDBR32 in 32-bit mode or ENDBR64 in 64-bit mode), which changes the internal state machine from WAIT_FOR_ENDBRANCH back to IDLE. Thus every authorized target of an indirect JMP or CALL must begin with ENDBRANCH. If the processor is in a WAIT_FOR_ENDBRANCH state (meaning, the previous instruction was an indirect JMP or CALL), and the next instruction is not an ENDBRANCH instruction, the processor generates an INT #21 (Control Flow Protection Fault). On processors not supporting CET indirect branch tracking, ENDBRANCH instructions are interpreted as NOPs and have no effect. === Microsoft Control Flow Guard === Control Flow Guard (CFG) was first released for Windows 8.1 Update 3 (KB3000850) in November 2014. Developers can add CFG to their programs by adding the /guard:cf linker flag before program linking in Visual Studio 2015 or newer. As of Windows 10 Creators Update (Windows 10 version 1703), the Windows kernel is compiled with CFG. The Windows kernel uses Hyper-V to prevent malicious kernel code from overwriting the CFG bitmap. CFG operates by creating a per-process bitmap, where a set bit indicates that the address is a valid destination. Before performing each indirect function call, the application checks if the destination address is in the bitmap. If the destination address is not in the bitmap, the program terminates. This makes it more difficult for an attacker to exploit a use-after-free by replacing an object's contents and then using an indirect function call to execute a payload. ==== Implementation details ==== For all protected indirect function calls, the _guard_check_icall function is called, which performs the following steps: Convert the target address to an offset and bit number in the bitmap. The highest 3 bytes are the byte offset in the bitmap The bit offset is a 5-bit value. The first four bits are the 4th through 8th low-order bits of the address. The 5th bit of the bit offset is set to 0 if the destination address is aligned with 0x10 (last four bits are 0), and 1 if it is not. Examine the target's address value in the bitmap If the target address is in the bitmap, return without an error. If the target address is not in the bitmap, terminate the program. ==== Bypass techniques ==== There are several generic techniques for bypassing CFG: Set the destination to code located in a non-CFG module loaded in the same process. Find an indirect call that was not protected by CFG (either CALL or JMP). Use a function call with a different number of arguments than the call is designed for, causing a stack misalignment, and code execution after the function returns (patched in Windows 10). Use a function call with the same number of arguments, but one of pointers passed is treated as an object and writes to a pointer-based offset, allowing overwriting a return address. Overwrite the function call used by the CFG to validate the address (patched in March 2015) Set the CFG bitmap to all 1's, allowing all indirect function calls Use a controlled-write primitive to overwrite an address on the stack (since the stack is not protected by CFG) === Microsoft eXtended Flow Guard === eXtended Flow Guard (XFG) has not been officially released yet, but is available in the Windows Insider preview and was publicly presented at Bluehat Shanghai in 2019. XFG extends CFG by validating function call signatures to ensure that indirect function calls are only to the subset of functions with the same signature. Function call signature validation is implemented by adding instructions to store the target function's hash in register r10 immediately prior to the indirect call and storing the calculated function hash in the memory immediately preceding the target address's code. When the indirect call is made, the XFG validation function compares the value in r10 to the target
Liveness test
A liveness test, liveness check or liveness detection is an automated method for determining whether a subject is a real person or part of a spoofing attack. The technique is used as part of know your customer checks in financial services and during facial age estimation. Liveness detection is a cornerstone of digital safety. == Test process == The threat in face spoofing attacks is that "the attacker only needs to find a good face swap library on Github and understand how to inject the model into the camera feed during the KYC process". Fraudsters usually buy stolen IDs on the dark web to start a deepfake attack. An AI-powered generative adversarial network (GAN) can then generate the face swapping model that many online verification services fail to detect. Low level hackers may use face swapping apps such as SwapFace, DeepFaceLive, and Swapstream (increasing interest for those apps in 2023 according to Google Trends). In a video liveness test, users are typically asked to look into a camera and to move, smile or blink, and features of their moving face may then be compared to that of a still image. Artificial intelligence is used to counter presentation attacks such as deepfakes or users wearing hyperrealistic masks, or video injection attacks. Other forms of liveness test include checking for a pulse when using a fingerprint scanner or checking that a person's voice is not a recording or artificially generated during speaker recognition. == Adoption and certification == In a 2022 report published by the security firm Sensity, it was demonstrated that the liveness test of most US banks was easily cheated with new and publicly-available AI-powered techniques. Many of these banks disregarded the results of the report. In the first half of 2023, the security firm iProov detected a 704% increase in face-swap attacks. In 2023, in the UK, many customers of Ryanair were upset to have to go through many ID verification checks, including liveness tests, before boarding, as the airline was using it as a mean to deter customers to buy tickets through third-party websites. In the first half of 2024 iBeta Quality Assurance issued 18 new ISO/IEC 30107-3 Presentation Attack Detection certificates, raising the cumulative total to 85 since 2018. In January 2024, the Department of Homeland Security (DHS) opened applications from vendors to test their Liveness test. Identity frauds peaked during the COVID-19 lockdown, leading government agencies to take reinforced measures to secure their digital applications.