AI-assisted targeting in the Gaza Strip

AI-assisted targeting in the Gaza Strip

As part of the Gaza war, the Israel Defense Forces (IDF) have used artificial intelligence to rapidly and automatically perform much of the process of determining what to bomb. Israel has greatly expanded the bombing of the Gaza Strip, which in previous wars had been limited by the Israeli Air Force running out of targets. These tools include the Gospel, an AI which automatically reviews surveillance data looking for buildings, equipment and people thought to belong to the enemy, and upon finding them, recommends bombing targets to a human analyst who may then decide whether to pass it along to the field. Another is Lavender, an "AI-powered database" which lists tens of thousands of Palestinian men linked by AI to Hamas or Palestinian Islamic Jihad, and which is also used for target recommendation. Critics have argued the use of these AI tools puts civilians at risk, blurs accountability, and results in militarily disproportionate violence in violation of international humanitarian law. == The Gospel == Israel uses an AI system dubbed "Habsora", "the Gospel", to determine which targets the Israeli Air Force would bomb. It automatically provides a targeting recommendation to a human analyst, who decides whether to pass it along to soldiers in the field. The recommendations can be anything from individual fighters, rocket launchers, Hamas command posts, to private homes of suspected Hamas or Islamic Jihad members. AI can process military intelligence far faster than humans. Retired Lt Gen. Aviv Kohavi, head of the IDF until 2023, stated that the system could produce 100 bombing targets in Gaza a day, with real-time recommendations which ones to attack, where human analysts might produce 50 a year. A lecturer interviewed by NPR estimated these figures as 50–100 targets in 300 days for 20 intelligence officers, and 200 targets within 10–12 days for the Gospel. === Technological background === The Gospel uses machine learning, where an AI is tasked with identifying commonalities in vast amounts of data (e.g. scans of cancerous tissue, photos of a facial expression, surveillance of Hamas members identified by human analysts), then looking for those commonalities in new material. What information the Gospel uses is not known, but it is thought to combine surveillance data from diverse sources in enormous amounts. Recommendations are based on pattern-matching. A person with enough similarities to other people labeled as enemy combatants may be labelled a combatant themselves. Regarding the suitability of AIs for the task, NPR cited Heidy Khlaaf, engineering director of AI Assurance at the technology security firm Trail of Bits, as saying "AI algorithms are notoriously flawed with high error rates observed across applications that require precision, accuracy, and safety." Bianca Baggiarini, lecturer at the Australian National University's Strategic and Defence Studies Centre wrote AIs are "more effective in predictable environments where concepts are objective, reasonably stable, and internally consistent." She contrasted this with telling the difference between a combatant and non-combatant, which even humans frequently can't do. Khlaaf went on to point out that such a system's decisions depend entirely on the data it's trained on, and are not based on reasoning, factual evidence or causation, but solely on statistical probability. === Operation === The IAF ran out of targets to strike in the 2014 war and 2021 crisis. In an interview on France 24, investigative journalist Yuval Abraham of +972 Magazine stated that to maintain military pressure, and due to political pressure to continue the war, the military would bomb the same places twice. Since then, the integration of AI tools has significantly sped up the selection of targets. In early November, the IDF stated more than 12,000 targets in Gaza had been identified by the target administration division that uses the Gospel. NPR wrote on December 14 that it was unclear how many targets from the Gospel had been acted upon, but that the Israeli military said it was currently striking as many as 250 targets a day. The bombing, too, has intensified to what the December 14 article called an astonishing pace: the Israeli military stated at the time it had struck more than 22,000 targets inside Gaza, at a daily rate more than double that of the 2021 conflict, more than 3,500 of them since the collapse of the truce on December 1. Early in the offensive the head of the Air Force stated his forces only struck military targets, but added: "We are not being surgical." Once a recommendation is accepted, another AI, Fire Factory, cuts assembling the attack down from hours to minutes by calculating munition loads, prioritizing and assigning targets to aircraft and drones, and proposing a schedule, according to a pre-war Bloomberg article that described such AI tools as tailored for a military confrontation and proxy war with Iran. One change that The Guardian noted is that since senior Hamas leaders disappear into tunnels at the start of an offensive, systems such as the Gospel have allowed the IDF to locate and attack a much larger pool of more junior Hamas operatives. It cited an official who worked on targeting decisions in previous Gaza operations as saying that while the homes of junior Hamas members had previously not been targeted for bombing, the official believes the houses of suspected Hamas operatives were now targeted regardless of rank. In the France 24 interview, Abraham, of +972 Magazine, characterized this as enabling the systematization of dropping a 2000 lb bomb into a home to kill one person and everybody around them, something that had previously been done to a very small group of senior Hamas leaders. NPR cited a report by +972 Magazine and its sister publication Local Call as asserting the system is being used to manufacture targets so that Israeli military forces can continue to bombard Gaza at an enormous rate, punishing the general Palestinian population. NPR noted it had not verified this; it was unclear how many targets are being generated by AI alone, but there had been a substantial increase in targeting, with an enormous civilian toll. In principle, the combination of a computer's speed to identify opportunities and a human's judgment to evaluate them can enable more precise attacks and fewer civilian casualties. Israeli military and media have emphasized this capacity to minimize harm to non-combatants. Richard Moyes, researcher and head of the NGO Article 36, pointed to "the widespread flattening of an urban area with heavy explosive weapons" to question these claims, while Lucy Suchman, professor emeritus at Lancaster University, described the bombing as "aimed at maximum devastation of the Gaza Strip". The Guardian wrote that when a strike was authorized on private homes of those identified as Hamas or Islamic Jihad operatives, target researchers knew in advance the expected number of civilians killed, each target had a file containing a collateral damage score stipulating how many civilians were likely to be killed in a strike, and according to a senior Israeli military source, operatives use a "very accurate" measurement of the rate of civilians evacuating a building shortly before a strike. "We use an algorithm to evaluate how many civilians are remaining. It gives us a green, yellow, red, like a traffic signal." ==== 2021 use ==== Kohavi compared the target division using the Gospel to a machine and stated that once the machine was activated in the war of May 2021, it generated 100 targets a day, with half of them being attacked, in contrast with 50 targets in Gaza per year beforehand. Approximately 200 targets came from the Gospel out of the 1,500 targets Israel struck in Gaza in the war, including both static and moving targets according to the military. The Jewish Institute for National Security of America's after action report identified an issue, stating the system had data on what was a target, but lacked data on what wasn't. The system depends entirely on training data, and intel that human analysts had examined and deemed didn't constitute a target had been discarded, risking bias. The vice president expressed his hopes this had since been rectified. === Organization === The Gospel is used by the military's target administration division (or Directorate of Targets or Targeting Directorate), which was formed in 2019 in the IDF's intelligence directorate to address the air force running out of targets to bomb, and which Kohavi described as "powered by AI capabilities" and including hundreds of officers of soldiers. In addition to its wartime role, The Guardian wrote it'd helped the IDF build a database of between 30,000 and 40,000 suspected militants in recent years, and that systems such as the Gospel had played a critical role in building lists of individuals authorized to be assassinated. The Gospel was developed by Unit 8200 of the Israeli Intelligence C

List of C software and tools

This is a list of software and programming tools for the C programming language, including libraries, debuggers, compilers, integrated development environments (IDEs), and other related development tools and utilities. == Libraries and tools == Adns — asynchronous DNS resolver library Advanced Linux Sound Architecture — API for sound card device drivers Allegro — cross-platform software library for video game development Apache Portable Runtime — Apache web server tool set of APIs that map to the underlying operating system Argon2 — memory-hard password hashing library Berkeley DB — embedded database software library for key/value data Binary File Descriptor library — binary file manipulation library in the GNU toolchain Boehm garbage collector – conservative garbage collector Borland Graphics Interface — graphics library for Borland compilers BSAFE — FIPS 140-2 validated cryptography library Chipmunk — 2D real-time rigid body physics engine C POSIX library — specification of a C standard library for POSIX systems C standard library – standard library for the C programming language Cairo – vector graphics library API for software developers CFD General Notation System (CGNS) — data format and library for computational fluid dynamics cJSON — lightweight JSON parser CLIPS — public-domain software tool for building expert systems Core Audio — low-level API for dealing with sound in Apple's macOS and iOS operating systems Core Foundation — API for macOS and iOS and other Apple operating systems Core Image — GPU accelerated image processing technology for Apple operating systems with Quartz graphics rendering layer. Core Text — text layout and font rendering API for macOS and iOS. Cryptlib — portable cryptography library cURL / libcurl — CLI app for uploading and downloading individual files, such as a URL from a web server over HTTP. DevIL — cross-platform image library for loading and converting file formats DirectFB — graphics acceleration and input device handling library Dld — dynamic loading library Expat — stream-oriented XML 1.0 parser library, written in C99. FFmpeg — multimedia framework for audio/video processing Fontconfig — font customization and configuration library FreeTDS — database library for Sybase and Microsoft SQL Server FreeType — render text onto bitmaps with a font rasterization engine GD Graphics Library — image creation and manipulation library GDK — graphics abstraction layer for GTK GEGL — graph-based image processing framework GIO — I/O and virtual file system library in GLib GLib — utility library providing data structures, event loops, and portability functions. glibc — GNU implementation of the C standard library GLFW — library for OpenGL contexts, windows, and input device handling GNet — networking library for GLib GNU Libtool — Library management tool GNU portability library — collection of portability routines for GNU software GNU Portable Threads — POSIX/ANSI-C based user space thread library for UNIX for scheduling multithreading GNU Readline — command-line editing library GnuTLS — secure communications (TLS/SSL) library GObject — object system library for GNOME GTK — widget toolkit for creating graphical user interfaces GTK Scene Graph Kit (GSK) — scene graph and rendering toolkit for GTK HDF — file format and library for managing large datasets Integrated Performance Primitives — Intel library of optimized multimedia and data processing routines IUP — portable GUI toolkit J2K-Codec — JPEG 2000 image codec JasPer — reference implementation of the codec specified in the JPEG-2000 Part-1 standard LDAP API — API for interacting with Lightweight Directory Access Protocol LZO — lossless compression library Liba52 — decoder for A/52 (AC-3) audio streams libarchive — reading and writing various archive and compression formats Libart — 2D graphics library Libavcodec — codec library from FFmpeg Libavdevice — library for handling multimedia devices Libavfilter — audio and video filter library Libavformat — library for muxing and demuxing multimedia Libpcap — packet capture library Libdca — decoder for DTS audio Libdvdcss — access to encrypted DVD-Video discs libevent — asynchronous event notification callbacks libffi — foreign function interface libfuse — userspace filesystem Libgegl — programming interface to GEGL image processing libgcrypt — cryptography Libgimp — plug-in development library for GIMP Libhybris — compatibility layer for running Android libraries on Linux Libinput — input device library for Wayland and X.Org libjpeg — JPEG image library libLAS — reading and writing geospatial data encoded in the ASPRS laser (LAS) file format libmicrohttpd — small C library for embedding HTTP server functionality Libmpcodecs — media player codec library from MPlayer Libmpdemux — demultiplexing library from MPlayer libpng — PNG image format Libpostproc — video post-processing library from FFmpeg libpq — PostgreSQL client LibreSSL — fork of OpenSSL for TLS Librsb — parallel library for sparse matrix computations Librsvg — SVG rendering library libsndfile — reading and writing audio files libsodium — easy-to-use cryptography library Libswscale — image scaling and colorspace conversion library LibTIFF — TIFF image handling library Libusb — USB device access library Libuv — asynchronous I/O and event loop library LibVLC — media player engine from VLC LibVNCServer — implementation of the VNC server protocol Libvpx — VP8 and VP9 video codec library Libwww — early World Wide Web protocol library from W3C libxml2 — XML parsing Libxslt — XSLT library for the GNOME Project libzip — ZIP archives Lightning Memory-Mapped Database — fast key–value database engine LittleCMS — open-source color management system LZ4 — fast lossless compression algorithm LZFSE — compression library developed by Apple MatrixSSL — lightweight TLS implementation Mbed TLS — portable cryptography and TLS library MediaLib — Sun Microsystems library for multimedia processing Mesa — OpenGL and Vulkan graphics library Microwindows — small windowing system for embedded devices Ming — library for generating SWF (Flash) files Mongoose — embedded web server and networking library Mpg123 — MP3 audio decoding library MPIR — multiple-precision arithmetic library MsQuic — Microsoft implementation of the QUIC transport protocol MuJoCo — physics engine for robotics and control Mustache — logic-less templating library Ncurses — terminal control library Nettle — low-level cryptography library Newt — text-based user interface library Netpbm — graphics conversion and processing library Nghttp2 — implementation of the HTTP/2 protocol Oniguruma — regular expression library Open Asset Import Library — library to import/export 3D model formats OpenCL — parallel computing API/library OpenCV — computer vision OpenGL — API for rendering 2D and 3D vector graphics OpenGL Utility Library — OpenGL utility functions OpenJPEG — JPEG 2000 image codec OpenSSL — SSL and TLS protocols and cryptography library Pango — layout engine library which works with the HarfBuzz shaping engine for displaying multi-language text perf (Linux) — performance analyzing tool PCRE — regular expression library PROJ — library for map projections and coordinate transforms Quartz 2D — 2D graphics rendering API for macOS and iOS platforms, part of the Core Graphics framework. Raylib — simple library for games and multimedia Redland RDF Application Framework — RDF data storage library S2n-tls — TLS implementation from AWS Setcontext — context switching library functions SDL — Simple DirectMedia Layer systemd — system and service manager libraries for Linux Tk — GUI widgets for building graphical user interfaces VDPAU — video decoding acceleration API Vorbis — audio compression codec library VTD-XML — high-performance XML parser Wimlib — library for handling Windows Imaging Format disk images Windows.h — base Windows API header file WolfSSH — lightweight SSH library WolfSSL — lightweight SSL/TLS library X Toolkit Intrinsics — toolkit library for the X Window System x264 — H.264 video codec library XCB — C binding for the X Window System protocol Xft — font rendering library using FreeType Xlib — low-level X Window System API XMDF — eXtensible Model Data Format for scientific data XMLStarlet — XML command-line toolkit zlib — data compression Zopfli — data compression library that performs deflate, gzip and zlib data encoding. Zstd — fast data compression library == Integrated development environments == Anjuta — GNOME IDE CLion — cross-platform commercial IDE from JetBrains Code::Blocks — cross-platform open-source IDE CodeLite — open-source IDE Dev-C++ Eclipse CDT Geany — text editor with IDE features KDevelop — KDE IDE NetBeans Qt Creator SlickEdit Visual Studio Xcode === Online IDEs === CodeSandbox — online IDE primarily for web development with some C support via containers GitHub Codespaces — cloud-based online IDE developed by GitHub Google Cloud Shell — browser-based shell and editor that can comp

Transfer function matrix

In control system theory, and various branches of engineering, a transfer function matrix, or just transfer matrix is a generalisation of the transfer functions of single-input single-output (SISO) systems to multiple-input and multiple-output (MIMO) systems. The matrix relates the outputs of the system to its inputs. It is a particularly useful construction for linear time-invariant (LTI) systems because it can be expressed in terms of the s-plane. In some systems, especially ones consisting entirely of passive components, it can be ambiguous which variables are inputs and which are outputs. In electrical engineering, a common scheme is to gather all the voltage variables on one side and all the current variables on the other regardless of which are inputs or outputs. This results in all the elements of the transfer matrix being in units of impedance. The concept of impedance (and hence impedance matrices) has been borrowed into other energy domains by analogy, especially mechanics and acoustics. Many control systems span several different energy domains. This requires transfer matrices with elements in mixed units. This is needed both to describe transducers that make connections between domains and to describe the system as a whole. If the matrix is to properly model energy flows in the system, compatible variables must be chosen to allow this. == General == A MIMO system with m outputs and n inputs is represented by a m × n matrix. Each entry in the matrix is in the form of a transfer function relating an output to an input. For example, for a three-input, two-output system, one might write, [ y 1 y 2 ] = [ g 11 g 12 g 13 g 21 g 22 g 23 ] [ u 1 u 2 u 3 ] {\displaystyle {\begin{bmatrix}y_{1}\\y_{2}\end{bmatrix}}={\begin{bmatrix}g_{11}&g_{12}&g_{13}\\g_{21}&g_{22}&g_{23}\end{bmatrix}}{\begin{bmatrix}u_{1}\\u_{2}\\u_{3}\end{bmatrix}}} where the un are the inputs, the ym are the outputs, and the gmn are the transfer functions. This may be written more succinctly in matrix operator notation as, Y = G U {\displaystyle \mathbf {Y} =\mathbf {G} \mathbf {U} } where Y is a column vector of the outputs, G is a matrix of the transfer functions, and U is a column vector of the inputs. In many cases, the system under consideration is a linear time-invariant (LTI) system. In such cases, it is convenient to express the transfer matrix in terms of the Laplace transform (in the case of continuous time variables) or the z-transform (in the case of discrete time variables) of the variables. This may be indicated by writing, for instance, Y ( s ) = G ( s ) U ( s ) {\displaystyle \mathbf {Y} (s)=\mathbf {G} (s)\mathbf {U} (s)} which indicates that the variables and matrix are in terms of s, the complex frequency variable of the s-plane arising from Laplace transforms, rather than time. The examples in this article are all assumed to be in this form, although that is not explicitly indicated for brevity. For discrete time systems s is replaced by z from the z-transform, but this makes no difference to subsequent analysis. The matrix is particularly useful when it is a proper rational matrix, that is, all its elements are proper rational functions. In this case, the state-space representation can be applied. In systems engineering, the overall system transfer matrix G (s) is decomposed into two parts: H (s) representing the system being controlled, and C(s) representing the control system. C (s) takes as its inputs the inputs of G (s) and the outputs of H (s). The outputs of C (s) form the inputs for H (s). == Electrical systems == In electrical systems, it is often the case that the distinction between input and output variables is ambiguous. They can be either, depending on circumstance and point of view. In such cases, the concept of port (a place where energy is transferred from one system to another) can be more useful than input and output. It is customary to define two variables for each port (p): the voltage across it (Vp) and the current entering it (Ip). For instance, the transfer matrix of a two-port network can be defined as follows, [ V 1 V 2 ] = [ z 11 z 12 z 21 z 22 ] [ I 1 I 2 ] {\displaystyle {\begin{bmatrix}V_{1}\\V_{2}\end{bmatrix}}={\begin{bmatrix}z_{11}&z_{12}\\z_{21}&z_{22}\\\end{bmatrix}}{\begin{bmatrix}I_{1}\\I_{2}\end{bmatrix}}} where the zmn are called the impedance parameters, or z-parameters. They are so-called because they are in units of impedance and relate port currents to a port voltage. The z-parameters are not the only way that transfer matrices are defined for two-port networks. Six basic matrices relate voltages and currents, each with advantages for particular system network topologies. However, only two of these can be extended beyond two ports to an arbitrary number of ports. These two are the z-parameters and their inverse, the admittance parameters or y-parameters. To understand the relationship between port voltages and currents and inputs and outputs, consider the simple voltage divider circuit. If we only wish to consider the output voltage (V2) resulting from applying the input voltage (V1) then the transfer function can be expressed as, [ V 2 ] = [ R 2 R 1 + R 2 ] [ V 1 ] {\displaystyle {\begin{bmatrix}V_{2}\end{bmatrix}}={\begin{bmatrix}{\dfrac {R_{2}}{R_{1}+R_{2}}}\end{bmatrix}}{\begin{bmatrix}V_{1}\end{bmatrix}}} which can be considered the trivial case of a 1×1 transfer matrix. The expression correctly predicts the output voltage if there is no current leaving port 2, but is increasingly inaccurate as the load increases. If, however, we attempt to use the circuit in reverse, driving it with a voltage at port 2 and calculate the resulting voltage at port 1 the expression gives completely the wrong result even with no load on port 1. It predicts a greater voltage at port 1 than was applied at port 2, an impossibility with a purely resistive circuit like this one. To correctly predict the behaviour of the circuit, the currents entering or leaving the ports must also be taken into account, which is what the transfer matrix does. The impedance matrix for the voltage divider circuit is, [ V 1 V 2 ] = [ R 1 + R 2 R 2 R 2 R 2 ] [ I 1 I 2 ] {\displaystyle {\begin{bmatrix}V_{1}\\V_{2}\end{bmatrix}}={\begin{bmatrix}R_{1}+R_{2}&R_{2}\\R_{2}&R_{2}\end{bmatrix}}{\begin{bmatrix}I_{1}\\I_{2}\end{bmatrix}}} which fully describes its behaviour under all input and output conditions. At microwave frequencies, none of the transfer matrices based on port voltages and currents are convenient to use in practice. Voltage is difficult to measure directly, current next to impossible, and the open circuits and short circuits required by the measurement technique cannot be achieved with any accuracy. For waveguide implementations, circuit voltage and current are entirely meaningless. Transfer matrices using different sorts of variables are used instead. These are the powers transmitted into, and reflected from a port, which are readily measured in the transmission line technology used in distributed-element circuits in the microwave band. The most well-known and widely used of these sorts of parameters is the scattering parameters, or s-parameters. == Mechanical and other systems == The concept of impedance can be extended into the mechanical and other domains through a mechanical-electrical analogy, hence the impedance parameters and other forms of 2-port network parameters can also be extended to the mechanical domain. To do this, an effort variable and a flow variable are made analogues of voltage and current, respectively. For mechanical systems under translation these variables are force and velocity respectively. Expressing the behaviour of a mechanical component as a two-port or multi-port with a transfer matrix is a useful thing to do because, like electrical circuits, the component can often be operated in reverse and its behaviour is dependent on the loads at the inputs and outputs. For instance, a gear train is often characterised simply by its gear ratio, a SISO transfer function. However, the gearbox output shaft can be driven around to turn the input shaft, requiring a MIMO analysis. In this example, the effort and flow variables are torque T and angular velocity ω, respectively. The transfer matrix in terms of z-parameters will look like, [ T 1 T 2 ] = [ z 11 z 12 z 21 z 22 ] [ ω 1 ω 2 ] {\displaystyle {\begin{bmatrix}T_{1}\\T_{2}\end{bmatrix}}={\begin{bmatrix}z_{11}&z_{12}\\z_{21}&z_{22}\end{bmatrix}}{\begin{bmatrix}\omega _{1}\\\omega _{2}\end{bmatrix}}} However, the z-parameters are not necessarily the most convenient for characterising gear trains. A gear train is the analogue of an electrical transformer and the h-parameters (hybrid parameters) better describe transformers because they directly include the turns ratios (the analogue of gear ratios). The gearbox transfer matrix in h-parameter format is, [ T 1 ω 2 ] = [ h 11 h 12 h 21 h 22 ] [ ω 1 T 2 ] {\displaystyle {\begin{bmatrix}T_{1}\\\omega _{2}\end{bm

Smoothing

In statistics and image processing, to smooth a data set is to create an approximating function that attempts to capture important patterns in the data, while leaving out noise or other fine-scale structures/rapid phenomena. In smoothing, the data points of a signal are modified so individual points higher than the adjacent points (presumably because of noise) are reduced, and points that are lower than the adjacent points are increased, leading to a smoother signal. Reducing noise by smoothing may aid in data analysis in two notable ways: Help uncover more meaningful information from the underlying data, such as trends. Provide analyses that are both flexible and robust. Many different algorithms are used in smoothing, most commonly binning, kernels, and local weighted regression. == Compared to curve fitting == Smoothing may be distinguished from the related and partially overlapping concept of curve fitting in the following ways: curve fitting often involves the use of an explicit function form for the result, whereas the immediate results from smoothing are the "smoothed" values with no later use made of a functional form if there is one; the aim of smoothing is to give a general idea of relatively slow changes of value with little attention paid to the close matching of data values, while curve fitting concentrates on achieving as close a match as possible. smoothing methods often have an associated tuning parameter which is used to control the extent of smoothing. Curve fitting will adjust any number of parameters of the function to obtain the 'best' fit. == Linear smoothers == In the case that the smoothed values can be written as a linear transformation of the observed values, the smoothing operation is known as a linear smoother; the matrix representing the transformation is known as a smoother matrix or hat matrix. The operation of applying such a matrix transformation is called convolution. Thus the matrix is also called convolution matrix or a convolution kernel. In the case of simple series of data points (rather than a multi-dimensional image), the convolution kernel is a one-dimensional vector. == Algorithms == One of the most common algorithms is the "moving average", often used to try to capture important trends in repeated statistical surveys. In image processing and computer vision, smoothing ideas are used in scale space representations. The simplest smoothing algorithm is the "rectangular" or "unweighted sliding-average smooth". This method replaces each point in the signal with the average of "m" adjacent points, where "m" is a positive integer called the "smooth width". Usually m is an odd number. The triangular smooth is like the rectangular smooth except that it implements a weighted smoothing function. Some specific smoothing and filter types, with their respective uses, pros and cons are:

Human–robot interaction

Human–robot interaction (HRI) is the study of interactions between humans and robots. Human–robot interaction is a multidisciplinary field with contributions from human–computer interaction, artificial intelligence, robotics, natural language processing, design, psychology and philosophy. A subfield known as physical human–robot interaction (pHRI) has tended to focus on device design to enable people to safely interact with robotic systems. == Origins == Human–robot interaction has been a topic of both science fiction and academic speculation even before any robots existed. Because much of active HRI development depends on natural language processing, many aspects of HRI are continuations of human communications, a field of research which is much older than robotics. The origin of HRI as a discrete problem was stated by 20th-century author Isaac Asimov in 1941, in his novel I, Robot. Asimov coined Three Laws of Robotics, namely: A robot may not injure a human being or, through inaction, allow a human being to come to harm. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws. These three laws provide an overview of the goals engineers and researchers hold for safety in the HRI field, although the fields of robot ethics and machine ethics are more complex than these three principles. However, generally human–robot interaction prioritizes the safety of humans that interact with potentially dangerous robotics equipment. Solutions to this problem range from the philosophical approach of treating robots as ethical agents (individuals with moral agency), to the practical approach of creating safety zones. These safety zones use technologies such as lidar to detect human presence or physical barriers to protect humans by preventing any contact between machine and operator. Although initially robots in the human–robot interaction field required some human intervention to function, research has expanded this to the extent that fully autonomous systems are now far more common than in the early 2000s. Autonomous systems include from simultaneous localization and mapping systems which provide intelligent robot movement to natural-language processing and natural-language generation systems which allow for natural, human-esque interaction which meet well-defined psychological benchmarks. Anthropomorphic robots (machines which imitate human body structure) are better described by the biomimetics field, but overlap with HRI in many research applications. Examples of robots which demonstrate this trend include Willow Garage's PR2 robot, the NASA Robonaut, and Honda ASIMO. However, robots in the human–robot interaction field are not limited to human-like robots: Paro and Kismet are both robots designed to elicit emotional response from humans, and so fall into the category of human–robot interaction. Goals in HRI range from industrial manufacturing through Cobots, medical technology through rehabilitation, autism intervention, and elder care devices, entertainment, human augmentation, and human convenience. Future research therefore covers a wide range of fields, much of which focuses on assistive robotics, robot-assisted search-and-rescue, and space exploration. == The goal of friendly human–robot interactions == Robots are artificial agents with capacities of perception and action in the physical world often referred by researchers as workspace. Their use has been generalized in factories but nowadays they tend to be found in the most technologically advanced societies in such critical domains as search and rescue, military battle, mine and bomb detection, scientific exploration, law enforcement, entertainment and hospital care. These new domains of applications imply a closer interaction with the user, sharing the workspace but also goals in terms of task achievement. The subfield of physical human–robot interaction (pHRI) has largely focused on device design to enable people to safely interact with robotic systems but is increasingly developing algorithmic approaches in an attempt to support fluent and expressive interactions between humans and robotic systems. With the advance in AI, the research is focusing on one part towards the safest physical interaction but also on a socially correct interaction, dependent on cultural criteria. The goal is to build an intuitive, and easy communication with the robot through speech, gestures, and facial expressions. Kerstin Dautenhahn refers to friendly Human–robot interaction as "Robotiquette" defining it as the "social rules for robot behaviour (a 'robotiquette') that is comfortable and acceptable to humans" The robot has to adapt itself to our way of expressing desires and orders and not the contrary. But every day environments such as homes have much more complex social rules than those implied by factories or even military environments. Thus, the robot needs perceiving and understanding capacities to build dynamic models of its surroundings. It needs to categorize objects, recognize and locate humans and further recognize their emotions. The need for dynamic capacities pushes forward every sub-field of robotics. Furthermore, by understanding and perceiving social cues, robots can enable collaborative scenarios with humans. For example, with the rapid rise of personal fabrication machines such as desktop 3D printers, laser cutters, etc., entering our homes, scenarios may arise where robots can collaboratively share control, co-ordinate and achieve tasks together. Industrial robots have already been integrated into industrial assembly lines and are collaboratively working with humans. The social impact of such robots have been studied and has indicated that workers still treat robots and social entities, rely on social cues to understand and work together. On the other end of HRI research the cognitive modelling of the "relationship" between human and the robots benefits the psychologists and robotic researchers the user study are often of interests on both sides. This research endeavours part of human society. For effective human – humanoid robot interaction numerous communication skills and related features should be implemented in the design of such artificial agents/systems. == General HRI research == HRI research spans a wide range of fields, some general to the nature of HRI. === Methods for perceiving humans === Methods for perceiving humans in the environment are based on sensor information. Research on sensing components and software led by Microsoft provide useful results for extracting the human kinematics (see Kinect). An example of older technique is to use colour information for example the fact that for light skinned people the hands are lighter than the clothes worn. In any case a human modelled a priori can then be fitted to the sensor data. The robot builds or has (depending on the level of autonomy the robot has) a 3D mapping of its surroundings to which is assigned the humans locations. Most methods intend to build a 3D model through vision of the environment. The proprioception sensors permit the robot to have information over its own state. This information is relative to a reference. Theories of proxemics may be used to perceive and plan around a person's personal space. A speech recognition system is used to interpret human desires or commands. By combining the information inferred by proprioception, sensor and speech the human position and state (standing, seated). In this matter, natural-language processing is concerned with the interactions between computers and human (natural) languages, in particular how to program computers to process and analyze large amounts of natural-language data. For instance, neural-network architectures and learning algorithms that can be applied to various natural-language processing tasks including part-of-speech tagging, chunking, named-entity recognition, and semantic role labeling. === Methods for motion planning === Motion planning in dynamic environments is a challenge that can at the moment only be achieved for robots with 3 to 10 degrees of freedom. Humanoid robots or even 2 armed robots, which can have up to 40 degrees of freedom, are unsuited for dynamic environments with today's technology. However lower-dimensional robots can use the potential field method to compute trajectories which avoid collisions with humans. === Cognitive models and theory of mind === Humans exhibit negative social and emotional responses as well as decreased trust toward some robots that closely, but imperfectly, resemble humans; this phenomenon has been termed the "Uncanny Valley". However recent research in telepresence robots has established that mimicking human body postures and expressive gestures has made the robots likeable and engaging in a remote setting. Further, the presence o

CPanel

cPanel is a web hosting control panel software developed by cPanel, L.L.C. It provides a graphical interface (GUI) and automation tools designed to simplify the process of hosting a web site for the website owner or "end user". It enables administration through a standard web browser using a three-tier structure. While cPanel is limited to managing a single hosting account, cPanel & WHM allow the administration of the entire server. In addition to the GUI, cPanel also has command line and API-based access that allows third-party software vendors, web hosting organizations, and developers to automate standard system administration processes. cPanel & WHM is designed to function either as a dedicated server or virtual private server. The latest cPanel & WHM version supports installation on AlmaLinux, Rocky Linux, CloudLinux OS, and Ubuntu. == History == cPanel is currently developed by cPanel, L.L.C., a privately owned company headquartered in Houston, Texas, United States. WebPros is the parent company of cPanel, L.L.C. It was originally designed in 1996 as the control panel for Speed Hosting, a now-defunct web hosting company. The original author of cPanel, J. Nick Koston, had a stake in Speed Hosting. Webking quickly began using cPanel after its merger with Speed Hosting. The new company moved its servers to Virtual Development Inc. (VDI), a now-defunct hosting facility. Following an agreement between Koston and VDI, cPanel was only available to customers hosted directly at VDI. At the time, there was little competition in the control panel market, with the main choices being VDI and Alabanza. Eventually, due to Koston leaving for college, he and William Jensen signed an agreement in which cPanel was split into a separate program called WebPanel; this version was run by VDI. Without the lead programmer, VDI was not able to continue any work on cPanel and eventually stopped supporting it completely. Koston kept working on cPanel while also working at BurstNET. Eventually, he left BurstNET to focus fully on cPanel. cPanel 3 was released in 1999: main additions over cPanel 2 were an automatic upgrade and the Web Host Manager (WHM). The interface was also improved when Carlos Rego of WizardsHosting made what became the default theme of cPanel. With the release of cPanel 11, cPanel adopted a four-tier versioning system, "Parent.Major.Minor.Patch" (e.g., 11.32.0.3). As of version 11.52, the "Parent" representation is deprecated, with 11.54 stylized as "Version 54." cPanel 11.30 is the last major version to support FreeBSD. On August 20, 2018 cPanel L.L.C. announced that it had signed an agreement to be acquired by a group led by Oakley Capital (who also own Plesk and SolusVM). While Koston sold his interest in cPanel, he will continue to be an owner of the company that owns cPanel. In April 2026, a severe vulnerability was discovered that affected all cPanel and WHM versions after 11.40, affectively allowing unauthenticated remote attackers to access the control panel. According to some web hosters the vulnerability was already being actively exploited, with some attempts even dating back to late February 2026. == Add-ons == cPanel provides front-ends for a number of common operations, including the management of PGP keys, crontab tasks, mail and FTP accounts, and mailing lists. Several add-ons exist, some for an additional fee, including auto installers such as Installatron, Fantastico, Softaculous, and WHMSonic (SHOUTcast/radio Control Panel Add-on). The add-ons need to be enabled by the server administrator in WHM to be accessible to the cPanel user. WHM manages some software packages separately from the underlying operating system, applying upgrades to Apache, PHP, MySQL and MariaDB, Exim, FTP, and related software packages automatically. This ensures that these packages are kept up-to-date and compatible with WHM, but makes it more difficult to install newer versions of these packages. It also makes it difficult to verify that the packages have not been tampered with, since the operating system's package management verification system cannot be used to do so. == WHM == WHM, short for WebHost Manager, is a web-based tool which is used for server administration. There are at least two tiers of WHM, often referred to as "root WHM", and non-root WHM (or Reseller WHM). Root WHM is used by server administrators and non-root WHM (with fewer privileges) is used by others, like entity departments, and resellers to manage hosting accounts often referred to as cPanel accounts on a web server. WHM is also used to manage SSL certificates (both server self generated and CA provided SSL certificates), cPanel users, hosting packages, DNS zones, themes, and authentication methods. The default automatic SSL (AutoSSL) provided by cPanel is powered by Let's Encrypt. Additionally, WHM can also be used to manage FTP, Mail (POP, IMAP, and SMTP) and SSH services on the server. As well as being accessible by the root administrator, WHM is also accessible to users with reseller privileges. Reseller users of cPanel have a smaller set of features than the root user, generally limited by the server administrator, to features which they determine will affect their customers' accounts rather than the server as a whole. From root WHM, the server administrator can perform maintenance operations such as upgrading and recompiling Apache and PHP, installing Perl modules, and upgrading RPMs installed on the system. == Enkompass == A version of cPanel & WHM for Microsoft Windows, called Enkompass, was declared end-of-life as of February 2014. Version 3 remained available for download, but without further development or support. In the preceding years, Enkompass had been available for free as product development slowed. == Pricing == On June 27, 2019 cPanel announced a new account-based pricing structure. After backlash from their customers, cPanel issued a second announcement but did not change the new structure.

Human–robot collaboration

Human-Robot Collaboration is the study of collaborative processes in human and robot agents work together to achieve shared goals. Many new applications for robots require them to work alongside people as capable members of human-robot teams. These include robots for homes, hospitals, and offices, space exploration and manufacturing. Human-Robot Collaboration (HRC) is an interdisciplinary research area comprising classical robotics, human-computer interaction, artificial intelligence, process design, layout planning, ergonomics, cognitive sciences, and psychology. Industrial applications of human-robot collaboration involve Collaborative Robots, or cobots, that physically interact with humans in a shared workspace to complete tasks such as collaborative manipulation or object handovers. == Collaborative Activity == Collaboration is defined as a special type of coordinated activity, one in which two or more agents work jointly with each other, together performing a task or carrying out the activities needed to satisfy a shared goal. The process typically involves shared plans, shared norms and mutually beneficial interactions. Although collaboration and cooperation are often used interchangeably, collaboration differs from cooperation as it involves a shared goal and joint action where the success of both parties depend on each other. For effective human-robot collaboration, it is imperative that the robot is capable of understanding and interpreting several communication mechanisms similar to the mechanisms involved in human-human interaction. The robot must also communicate its own set of intents and goals to establish and maintain a set of shared beliefs and to coordinate its actions to execute the shared plan. In addition, all team members demonstrate commitment to doing their own part, to the others doing theirs, and to the success of the overall task. == Theories Informing Human-Robot Collaboration == Human-human collaborative activities are studied in depth in order to identify the characteristics that enable humans to successfully work together. These activity models usually aim to understand how people work together in teams, how they form intentions and achieve a joint goal. Theories on collaboration inform human-robot collaboration research to develop efficient and fluent collaborative agents. === Belief Desire Intention Model === The belief-desire-intention (BDI) model is a model of human practical reasoning that was originally developed by Michael Bratman. The approach is used in intelligent agents research to describe and model intelligent agents. The BDI model is characterized by the implementation of an agent's beliefs (the knowledge of the world, state of the world), desires (the objective to accomplish, desired end state) and intentions (the course of actions currently under execution to achieve the desire of the agent) in order to deliberate their decision-making processes. BDI agents are able to deliberate about plans, select plans and execute plans. === Shared Cooperative Activity === Shared Cooperative Activity defines certain prerequisites for an activity to be considered shared and cooperative: mutual responsiveness, commitment to the joint activity and commitment to mutual support. An example case to illustrate these concepts would be a collaborative activity where agents are moving a table out the door, mutual responsiveness ensures that movements of the agents are synchronized; a commitment to the joint activity reassures each team member that the other will not at some point drop his side; and a commitment to mutual support deals with possible breakdowns due to one team member's inability to perform part of the plan. === Joint Intention Theory === Joint Intention Theory proposes that for joint action to emerge, team members must communicate to maintain a set of shared beliefs and to coordinate their actions towards the shared plan. In collaborative work, agents should be able to count on the commitment of other members, therefore each agent should inform the others when they reach the conclusion that a goal is achievable, impossible, or irrelevant. == Approaches to Human-Robot Collaboration == The approaches to human-robot collaboration include human emulation (HE) and human complementary (HC) approaches. Although these approaches have differences, there are research efforts to develop a unified approach stemming from potential convergences such as Collaborative Control. === Human Emulation === The human emulation approach aims to enable computers to act like humans or have human-like abilities in order to collaborate with humans. It focuses on developing formal models of human-human collaboration and applying these models to human-computer collaboration. In this approach, humans are viewed as rational agents who form and execute plans for achieving their goals and infer other people's plans. Agents are required to infer the goals and plans of other agents, and collaborative behavior consists of helping other agents to achieve their goals. === Human Complementary === The human complementary approach seeks to improve human-computer interaction by making the computer a more intelligent partner that complements and collaborates with humans. The premise is that the computer and humans have fundamentally asymmetric abilities. Therefore, researchers invent interaction paradigms that divide responsibility between human users and computer systems by assigning distinct roles that exploit the strengths and overcome the weaknesses of both partners. == Key Aspects == Specialization of Roles: Based on the level of autonomy and intervention, there are several human-robot relationships including master-slave, supervisor–subordinate, partner–partner, teacher–learner and fully autonomous robot. In addition to these roles, homotopy (a weighting function that allows a continuous change between leader and follower behaviors) was introduced as a flexible role distribution. Establishing shared goal(s): Through direct discussion about goals or inference from statements and actions, agents must determine the shared goals they are trying to achieve. Allocation of Responsibility and Coordination: Agents must decide how to achieve their goals, determine what actions will be done by each agent, and how to coordinate the actions of individual agents and integrate their results. Shared context: Agents must be able to track progress toward their goals. They must keep track of what has been achieved and what remains to be done. They must evaluate the effects of actions and determine whether an acceptable solution has been achieved. Communication: Any collaboration requires communication to define goals, negotiate over how to proceed and who will do what, and evaluate progress and results. Adaptation and learning: Collaboration over time require partners to adapt themselves to each other and learn from one's partner both directly or indirectly. Time and space: The time-space taxonomy divides human-robot interaction into four categories based on whether the humans and robots are using computing systems at the same time (synchronous) or different times (asynchronous) and while in the same place (collocated) or in different places (non-collocated). Ergonomics: Human factors and ergonomics are one of the key aspects for a sustainable human-robot collaboration. The robot control system can use biomechanical models and sensors to optimize various ergonomic metrics, such as muscle fatigue.