SERVQUAL

SERVQUAL is a research tool that measures customer perception of service quality by comparing what customers expect from a service to their assessment of the service actually delivered. The instrument was developed in the United States in the mid-1980s by researchers A. Parasuraman, Valarie Zeithaml, and Leonard L. Berry, and is designed for use in after-service evaluation processes. It assesses service quality across five dimensions: reliability, assurance, tangibles, empathy, and responsiveness. SERVQUAL has been applied in sectors including healthcare, banking, education, and libraries. == Overview == The SERVQUAL questionnaire consists of matched pairs of items, 22 expectation items and 22 perception items, organized into five dimensions that correspond to the consumer's mental framework for evaluating service quality. Each item is part of a pair: one question asks what excellent organizations in a given industry should offer (expectation), and the other asks how the specific organization being evaluated performs (perception). == The model of service quality == The model of service quality, referred to as the gaps model, was developed by Parasuraman, Zeithaml, and Berry during a systematic research program conducted in the 1980s. The model identifies five gaps that may cause customers to experience poor service quality. In this framework, gap 5 is the service quality gap, which represents the difference between customer expectations and their perceptions of the service. This is the only gap that can be directly measured, and the SERVQUAL instrument was designed specifically to capture it. Gaps 1 through 4 have diagnostic value and point to probable causes of service failures. == Development of the instrument == Development of the model of service quality began in 1983 and, after iterative refinements, led to the publication of the SERVQUAL instrument in 1988. The research team conducted in-depth interviews and focus groups in four service sectors: retail banking, credit card services, securities brokerage, and product repair and maintenance. The questionnaire was tested across multiple samples to verify its reliability, validity, and factor structure. == Adaptations and variants == SERVQUAL has been adapted for specific industries and contexts. Well‑known derivatives include: LibQUAL+ – a library service quality survey developed by the Association of Research Libraries. EDUQUAL – an instrument tailored for the evaluation of service quality in educational institutions. HEALTHQUAL – adapted for measuring patient perceptions of healthcare service quality. ARTSQUAL – used to evaluate visitor perceptions of quality in museums and performing arts venues. == Criticisms == Researchers have raised several concerns about SERVQUAL. Critics argue that the instrument's definition of expectations is ambiguous and that it does not adequately account for the dynamic nature of customer expectations over time. Other scholars question whether the five‑dimension structure is universally applicable across all service contexts, and whether a generic instrument can capture the unique attributes of specific industries without modification.

Sorenson Squeeze

Sorenson Squeeze was a software video encoding tool used to compress and convert video and audio files on Mac OS X or Windows operating systems. It was sold as a standalone tool and has also long been bundled with Avid Media Composer. == History == Sorenson Squeeze was first announced on July 17, 2001, as the first variable bit rate (VBR) compression application for Mac OS X, and was released on October 29 of that same year. By March 2002, Sorenson Squeeze became available for Windows OS. Sorenson Squeeze was originally released as a tool for encoding videos for the Web and QuickTime playback but began adding new codecs as more versions were released. The software was discontinued by Sorenson in January 2019, and correspondingly was no longer offered as part of Avid Media Composer. == Features == Squeeze included a number of features to improve video & audio quality. Features included: GPU accelerated H.264 encoding, adaptive bitrate encoding, HD encoding and Dolby certified AC3 Audio. Intelligent encoding presets available in Squeeze included: x265 (H.265) MainConcept H.264 and MainConcept H.264 CUDA. Adaptive bitrate encoding allows for optimal bitrate and error resilience based on network conditions, resulting in a dynamic adjustment of the video bitstream being delivered. It encoded to multiple formats including QuickTime, Windows Media, Flash Video, Silverlight, WebM & WMV. It uses multiple codecs, including the Sorenson codecs SV3 Pro and Spark, H.265, H.264, H.263, VP6, VC1, MPEG2, and many others. Squeeze operates on the Apple Macintosh and Microsoft Windows operating systems. Squeeze offers native plugins to Avid, Apple Final Cut Pro and Adobe Premiere (CS4, CS5) NLEs. Each copy of Squeeze included the Dolby Certified AC3 Consumer encoder. Squeeze also included a simplified review and approval process, which allows the user to automatically send secure, password protected videos for immediate review. Instant feedback is received via Web or mobile. == Versions == Sorenson Squeeze was released on October 29, 2001. Sorenson Squeeze for Macromedia Flash MX was released on March 14, 2002. Sorenson Squeeze 3 for MPEG-4 was released in January 2003. Sorenson Squeeze 3 Compression Suite was released in January 2003. Sorenson Squeeze 5 was released on March 31, 2008. Sorenson Squeeze was updated to version 5.1 on May 11, 2009. Sorenson Squeeze 6 was released on November 3, 2009. Sorenson Squeeze 7 was released January 25, 2011. Sorenson Squeeze 11 was released August 27, 2016. == Awards == Streaming Media magazine Readers’ Choice Award for Encoding Software for 2007, 2008, 2009 and 2010. 2008 Vanguard Award from Digital Content Producer magazine == Squeeze 7 system requirements == Windows Pentium IV-based computer or greater Windows XP, Vista or 7 32- and 64-bit compatible (including AVID 64-bit update); Faster performance on 64-bit systems 512 MB RAM 120 MB available hard drive space QuickTime 7.2 or later DirectX 9.0b or later Macintosh Intel-based processor Mac OS 10.4 or later 32- and 64-bit compatible; Faster performance on 64-bit systems 512 MB RAM 120 MB available hard drive space QuickTime 7.2 or later

KoalaPad

The KoalaPad is a graphics tablet, released in 1983 by US company Koala Technologies Corporation, for the Apple II, TRS-80 Color Computer (as the TRS-80 Touch Pad), Atari 8-bit computers, Commodore 64, and IBM PC compatibles. Originally designed by Dr. David Thornburg as a low-cost computer drawing tool for schools, the Koala Pad and the bundled drawing program, KoalaPainter, was popular with home users as well. KoalaPainter was called KoalaPaint in some versions for the Apple II, and PC Design for the IBM PC. A program called Graphics Exhibitor was included for creating slideshow presentations from KoalaPainter drawings. == Description == The pad was four inches square (i.e. roughly 10×10 cm) and mounted on a slightly inclined base with the back of the pad higher than the front. At the top, "behind" the pad, were two buttons. The pad hooked into the computer using the analog signals of the joystick ports (the so-called paddle inputs), which meant that it had a low resolution and tended to jostle the cursor if moved during use. As an alternative to the drawing stylus, the pad could as easily be operated by the user's fingers for tasks that demanded less precision, such as selecting between menu items (thus using the pad as a kind of "indirect touch screen"). The top-mounted buttons tended to be somewhat frustrating to use, as the user had to "reach around" the stylus to push the buttons in order to start or stop drawing. A similar tablet from Atari, the Atari CX77 Touch Tablet, addressed this with a built-in button on the stylus, which some enterprising users adapted for use with their KoalaPad. == KoalaPainter == The pad shipped with a simple bitmap graphics editor developed by Audio Light called KoalaPainter, PC Design or Micro Illustrator depending on the target machine (see release history). Although bundled with the pad, KoalaPainter could also be operated using an ordinary digital joystick. One unique feature of the program, for its time, was that it held two pictures in the computer's memory, allowing the user to flip from one to the other—a function commonly used in order to study the differences between an original and a modified picture, and to copy and paste between two different pictures. Some third-party bitmap editors could also be used with the KoalaPad, such as Broderbund's Dazzle Draw for the Apple II. === Release history === KoalaPainter for Commodore 64 (1983) and Atari 8-bit computers (1983) PC Design for the IBM PC (1983) Micro Illustrator for the Apple II (1983), Atari 8-bit computers (1983) and Commodore Plus/4 (1984) KoalaPainter II for Commodore 64 (1984) === Reception === Ahoy! called KoalaPainter "a very powerful and effective color drawing package", and concluded that it and the KoalaPad were "excellent in ease of use, a fine choice for a beginner as well as young children". BYTE's reviewer stated in December 1984 that he made far fewer errors when using an Apple Mouse with MousePaint than with a KoalaPad and its software. He found that MousePaint was easier to use and more efficient, predicting that the mouse would receive more software support than the pad. Cassie Stahl in InfoWorld's Essential Guide to Atari Computers praised the tablet and its documentation, rating it "Excellent" among all categories and stating that "Playing with the KoalaPad becomes addictive. It does everything it claims to, and it does it well". She also liked Micro Illustrator, rating it "Excellent" except for "Good" for Performance. While criticizing the limited erase function, Stahl reported an undocumented feature enabling exporting pictures to other software. === File format === The Commodore 64 version of KoalaPainter used a fairly simple file format corresponding directly to the way bitmapped graphics are handled on the computer: A two-byte load address, followed immediately by 8,000 bytes of raw bitmap data, 1,000 bytes of raw "Video Matrix" data, 1,000 bytes of raw "Color RAM" data, and a one-byte Background Color field. == KoalaWare == Koala Technologies offered more software beyond the bundled KoalaPainter and Graphics Exhibitor for use with the pad. Among these applications, marketed under the moniker KoalaWare (like KoalaPainter itself), was educational software for use with customized keypads and overlays, such as spelling tools, music programs, and mathematics instruction software, as well as software for "translating" graphical designs into Logo programs.

Opponent process

The opponent process is a hypothesis of color vision that states that the human visual system interprets information about color by processing signals from the three types of photoreceptor cells in an antagonistic manner. The three types of cones are called L, M, and S. The names stand for "Long wavelength sensitive,” "middle wavelength sensitive," and "short wavelength sensitive." The opponent-process theory implicates three opponent channels: L versus M, S versus (L+M), and a luminance channel (+ versus -). These cone-opponent mechanisms were at one time thought to be the neural substrate for a psychological theory called Hering's Opponent Colors Theory, which calls for three psychologically important opponent color processes: red versus green, blue versus yellow, and black versus white (luminance). The Opponent Colors Theory is named for the German physiologist Ewald Hering who proposed the idea in the late 19th century. However, it has been argued that Hering’s Opponent Colors Theory lacks adequate phenomenological and empirical support, and may not be a necessary feature of normal human color experience. Correspondingly, considerable physiological and behavioral evidence proves that the physiological cone opponent mechanisms do not constitute the neurobiological basis for Hering's Opponent Colors Theory. == Color theory == === Complementary colors === When staring at a bright color for a while (e.g. red), then looking away at a white field, an afterimage is perceived, such that the original color will evoke its complementary color (cyan, in the case of red input). When complementary colors are combined or mixed, they "cancel each other out" and become neutral (white or gray). That is, complementary colors are never perceived as a mixture; there is no "greenish red" or "yellowish blue", despite claims to the contrary. The strongest color contrast that a color can have is its complementary color. Complementary colors may also be called "opposite colors" and they were originally considered the primary evidence in support of Hering's Opponent Colors Theory. There are two fatal problems with this evidence. First, the complement of red is not green, as called for by Hering's theory; it is bluish-green. And second, there exists a complementary color for every color, so there is nothing special about the set of complementary pairs picked out by Hering's theory. === Unique hues === The colors that define the extremes for each opponent channel are called unique hues, as opposed to composite (mixed) hues. Ewald Hering first defined the unique hues as red, green, blue, and yellow, and based them on the concept that these colors could not be simultaneously perceived. For example, a color cannot appear both red and green. These definitions have been experimentally refined and are represented today by average hue angles of 353° (carmine red), 128° (cobalt green), 228° (cobalt blue), 58° (yellow). The unique hues are a defining feature of many psychological color spaces, but there is substantial evidence showing that the unique hues are not hard wired in the nervous system, contrary to the stipulations of Hering's Opponent Colors Theory. Unique hues can differ between individuals and are often used in psychophysical research to measure variations in color perception due to color-vision deficiencies or color adaptation. While there is considerable inter-subject variability when defining unique hues experimentally, an individual's unique hues are very consistent, to within a few nanometers of wavelength. == Physiological basis == === Relation to LMS color space === The trichromatic theory is in conflict with Hering's Opponent Colors Theory, although it is compatible with a physiological opponent process that compares the outputs of the different classes of cone types. The poles of these cone opponent mechanisms do not correspond to the unique hues of Hering's Opponent Colors Theory and unlike the unique hues, have no privilege in color perception. Most humans have three different cone cells in their retinas that facilitate trichromatic color vision. Colors are determined by the proportional excitation of these three cone types, i.e. their quantum catch. The levels of excitation of each cone type are the parameters that define LMS color space. To calculate the opponent process tristimulus values from the LMS color space, the cone excitations must be compared: The luminous (achromatic) opponent channel is a weighted sum of all three cone cells (plus the rod cells in some conditions). The red–green opponent channel is equal to the difference of the L- and M-cones. The blue–yellow opponent channel is equal to the difference of the S-cone and the average/weighted sum of the L- and M-cones. Most mammals have no L cone (the primate L cone arose from a gene duplication of the M cone opsin gene). These mammals still show two kinds of opponent channels in their retinal ganglion cells: the achromatic channel and the blue-yellow opponency channel. === Cone opponent mechanisms are encoded in the retina === The output of different types of cones are compared by cells in the retina including retina bipolar cells (which compare signals from L and M cones) and bistratified retinal ganglion cells (which compare S cone signals with L and M cone signals). The output of bipolar cells is relayed to the visual cortex by the retinal ganglion cells (RGCs) by way of a thalamic relay station called the lateral geniculate nucleus (LGN) of the thalamus. Much of the scientific knowledge of retinal ganglion cell physiology was obtained by neural recordings of cells in the LGN. The cone-opponent mechanisms in the retina and LGN represent a fundamental physiological opponent process but do not represent the unique hues (or Hering's Opponent Colors Theory). For example, the colors that best elicit responses of the bistratified S-(L+M)-opponent neurons are best described as purplish (or lavender) and lime-green, not "blue" and "yellow". The neurons are sometimes referred to as "blue–yellow" neurons, but this is a historical artifact dating to the time when it was thought that Hering's Opponent Colors Theory was hardwired by the retina and the mismatch between the colors to which they are optimally tuned and Hering's Opponent Colors was overlooked. Cone opponent mechanisms exist in the retinas of many mammals, including monkeys, mice, and cats. In primates, the LGN contains three major classes of layers: Magnocellular layers (M, large-cell) – responsible largely for the luminance channel Parvocellular layers (P, small-cell) – responsible largely for red–green opponency Koniocellular layers (K) – responsible largely for blue–yellow opponency, poor spatial resolution, long latency Other mammals such as cats also have three cell types denoted as X (magno), Y (parvo), and W (konio). The W type is beyond most doubt homologous to the primate K type. There are some subtle differences between the M and X types as well as the Y and P types to make the correspondence unclear. === Advantage === Transmitting information in opponent-channel color space could be advantageous over transmitting it in LMS color space ("raw" signals from each cone type). There is some overlap in the wavelengths of light to which the three types of cones (L for long-wave, M for medium-wave, and S for short-wave light) respond, so it is more efficient for the visual system (from a perspective of dynamic range) to record differences between the responses of cones, rather than each type of cone's individual response. Hurvich and Jameson argued that the use of opponent-channel color space would increase color contrast, making the information easier to process by later stages of vision. === Color blindness === Color blindness can be classified by the cone cell that is affected (protan, deutan, tritan) or by the opponent channel that is affected (red–green or blue–yellow). In either case, the channel can either be inactive (in the case of dichromacy) or have a lower dynamic range (in the case of anomalous trichromacy). For example, individuals with deuteranopia see little difference between the red and green unique hues. == History == Johann Wolfgang von Goethe first studied the physiological effect of opposed colors in his Theory of Colours in 1810. Goethe arranged his color wheel symmetrically "for the colours diametrically opposed to each other in this diagram are those which reciprocally evoke each other in the eye. Thus, yellow demands purple; orange, blue; red, green; and vice versa: Thus again all intermediate gradations reciprocally evoke each other." Ewald Hering proposed opponent color theory in 1892. He thought that the colors red, yellow, green, and blue are special in that any other color can be described as a mix of them, and that they exist in opposite pairs. That is, either red or green is perceived and never greenish-red: Even though yellow is a mixture of red and green in the RGB color theory, humans

Plotly

Plotly is a technical computing company headquartered in Montreal, Quebec, that develops online data analytics and visualization tools. Plotly provides online graphing, analytics, and statistics tools for individuals and collaboration, as well as scientific graphing libraries for Python, R, MATLAB, Perl, Julia, Arduino, JavaScript and REST. == History == Plotly was founded by Alex Johnson, Jack Parmer, Chris Parmer, and Matthew Sundquist. The founders' backgrounds are in science, energy, and data analysis and visualization. Early employees include Christophe Viau, a Canadian software engineer and Ben Postlethwaite, a Canadian geophysicist. Plotly was named one of the Top 20 Hottest Innovative Companies in Canada by the Canadian Innovation Exchange. Plotly was featured in "startup row" at PyCon 2013, and sponsored the SciPy 2018 conference. Plotly raised $5.5 million during its Series A funding, led by MHS Capital, Siemens Venture Capital, Rho Ventures, Real Ventures, and Silicon Valley Bank. The Boston Globe and Washington Post newsrooms have produced data journalism using Plotly. In 2020, Plotly was named a Best Place to Work by the Canadian SME National Business Awards, and nominated as Business of the Year. == Products == Plotly offers open-source and enterprise products. Dash is an open-source Python, R, and Julia framework for building web-based analytic applications. Many specialized open-source Dash libraries exist that are tailored for building domain-specific Dash components and applications. Some examples are Dash DAQ, for building data acquisition GUIs to use with scientific instruments, and Dash Bio, which enables users to build custom chart types, sequence analysis tools, and 3D rendering tools for bioinformatics applications. Dash Enterprise is Plotly's paid product for building, testing, deploying, managing and scaling Dash applications organization-wide. Chart Studio Cloud is a free, online tool for creating interactive graphs. It has a point-and-click graphical user interface for importing and analyzing data into a grid and using stats tools. Graphs can be embedded or downloaded. Chart Studio Enterprise is a paid product that allows teams to create, style, and share interactive graphs on a single platform. It offers expanded authentication and file export options, and does not limit sharing and viewing. Data visualization libraries Plotly.js is an open-source JavaScript library for creating graphs and powers Plotly.py for Python, as well as Plotly.R for R, MATLAB, Node.js, Julia, and Arduino and a REST API. Plotly can also be used to style interactive graphs with Jupyter notebook. Figure converters which convert matplotlib, ggplot2, and IGOR Pro graphs into interactive, online graphs. == Data visualization libraries == Plotly provides a collection of supported chart types across several programming languages: == Dash == Dash is a Python framework built on top of React, a JavaScript library. Dash also works for R, and most recently supports Julia. While still described as a Python framework, Python isn't used for the other languages: "... describing Dash as a Python framework misses a key feature of its design: the Python side (the back end/server) of Dash was built to be lightweight and stateless [allowing] multiple back-end languages to coexist on an equal footing". It is possible to integrate D3.js charts as Dash components. Dash provides the default CSS (plus HTML and JavaScript), but for custom styling Dash applications, CSS can be added, or Dash Enterprise used. === Dash Enterprise === Dash Enterprise is Plotly's paid product for building, testing, deploying, managing and scaling Dash applications organization-wide. The product integrates with enterprise IT systems to enable organizations to build, deploy and scale low-code Dash applications. With open-source Dash, analytic applications can be run from a local machine, but cannot be easily accessed by others in the organization. ==== Enterprise IT integration ==== Dash Enterprise installs on cloud environments and on-premises. Amazon Web Services, Google Cloud Platform, and Microsoft Azure are supported, as are multiple Linux on-premises servers. Authentication integrations include LDAP, AD, PKI, Okta, SAML, OAuth2, SSO, and email authentication, and Dash application access is managed through a GUI rather than code. Dash Enterprise connects to major big data backends, including Salesforce, PostgreSQL, Databricks via PySpark, Snowflake, Dask, Datashader, and Vaex. In 2020, Plotly partnered with NVIDIA to integrate Dash with RAPIDS, and NVIDIA participated in Plotly's Series C funding round. ==== Low-code capabilities ==== Dash Enterprise enables low-code development of Dash applications, which is not possible with open-source Dash. Enterprise users can write applications in multiple development environments, including Jupyter Notebook. Dash Enterprise ships with several “development engines” for drag-and-drop application editing, application design, and automated reporting, as well as dozens of artificial intelligence and machine learning application templates. ==== Deployment and scaling ==== Dash application code is deployed to Dash Enterprise using the git-push command. Dash application deployments are containerized to avoid dependency conflicts, and can be embedded in existing web platforms without iframes. Deployed applications can be managed and accessed in a single portal called App Manager, where administrators can control user authentication and view usage analytics. Dash Enterprise scales horizontally with Kubernetes. Jobs queuing, GPU acceleration, and CPU parallelization support high performance computing requirements. Plotly also offers professional services for application development and workshop training.

Visual servoing

Visual servoing, also known as vision-based robot control and abbreviated VS, is a technique which uses feedback information extracted from a vision sensor (visual feedback) to control the motion of a robot. One of the earliest papers that talks about visual servoing was from the SRI International Labs in 1979. == Visual servoing taxonomy == There are two fundamental configurations of the robot end-effector (hand) and the camera: Eye-in-hand, or end-point open-loop control, where the camera is attached to the moving hand and observing the relative position of the target. Eye-to-hand, or end-point closed-loop control, where the camera is fixed in the world and observing the target and the motion of the hand. Visual Servoing control techniques are broadly classified into the following types: Image-based (IBVS) Position/pose-based (PBVS) Hybrid approach IBVS was proposed by Weiss and Sanderson. The control law is based on the error between current and desired features on the image plane, and does not involve any estimate of the pose of the target. The features may be the coordinates of visual features, lines or moments of regions. IBVS has difficulties with motions very large rotations, which has come to be called camera retreat. PBVS is a model-based technique (with a single camera). This is because the pose of the object of interest is estimated with respect to the camera and then a command is issued to the robot controller, which in turn controls the robot. In this case the image features are extracted as well, but are additionally used to estimate 3D information (pose of the object in Cartesian space), hence it is servoing in 3D. Hybrid approaches use some combination of the 2D and 3D servoing. There have been a few different approaches to hybrid servoing 2-1/2-D Servoing Motion partition-based Partitioned DOF Based == Survey == The following description of the prior work is divided into 3 parts Survey of existing visual servoing methods. Various features used and their impacts on visual servoing. Error and stability analysis of visual servoing schemes. === Survey of existing visual servoing methods === Visual servo systems, also called servoing, have been around since the early 1980s , although the term visual servo itself was only coined in 1987. Visual Servoing is, in essence, a method for robot control where the sensor used is a camera (visual sensor). Servoing consists primarily of two techniques, one involves using information from the image to directly control the degrees of freedom (DOF) of the robot, thus referred to as Image Based Visual Servoing (IBVS). While the other involves the geometric interpretation of the information extracted from the camera, such as estimating the pose of the target and parameters of the camera (assuming some basic model of the target is known). Other servoing classifications exist based on the variations in each component of a servoing system , e.g. the location of the camera, the two kinds are eye-in-hand and hand–eye configurations. Based on the control loop, the two kinds are end-point-open-loop and end-point-closed-loop. Based on whether the control is applied to the joints (or DOF) directly or as a position command to a robot controller the two types are direct servoing and dynamic look-and-move. Being one of the earliest works the authors proposed a hierarchical visual servo scheme applied to image-based servoing. The technique relies on the assumption that a good set of features can be extracted from the object of interest (e.g. edges, corners and centroids) and used as a partial model along with global models of the scene and robot. The control strategy is applied to a simulation of a two and three DOF robot arm. Feddema et al. introduced the idea of generating task trajectory with respect to the feature velocity. This is to ensure that the sensors are not rendered ineffective (stopping the feedback) for any the robot motions. The authors assume that the objects are known a priori (e.g. CAD model) and all the features can be extracted from the object. The work by Espiau et al. discusses some of the basic questions in visual servoing. The discussions concentrate on modeling of the interaction matrix, camera, visual features (points, lines, etc..). In an adaptive servoing system was proposed with a look-and-move servoing architecture. The method used optical flow along with SSD to provide a confidence metric and a stochastic controller with Kalman filtering for the control scheme. The system assumes (in the examples) that the plane of the camera and the plane of the features are parallel., discusses an approach of velocity control using the Jacobian relationship s˙ = Jv˙ . In addition the author uses Kalman filtering, assuming that the extracted position of the target have inherent errors (sensor errors). A model of the target velocity is developed and used as a feed-forward input in the control loop. Also, mentions the importance of looking into kinematic discrepancy, dynamic effects, repeatability, settling time oscillations and lag in response. Corke poses a set of very critical questions on visual servoing and tries to elaborate on their implications. The paper primarily focuses the dynamics of visual servoing. The author tries to address problems like lag and stability, while also talking about feed-forward paths in the control loop. The paper also, tries to seek justification for trajectory generation, methodology of axis control and development of performance metrics. Chaumette in provides good insight into the two major problems with IBVS. One, servoing to a local minima and second, reaching a Jacobian singularity. The author show that image points alone do not make good features due to the occurrence of singularities. The paper continues, by discussing the possible additional checks to prevent singularities namely, condition numbers of J_s and Jˆ+_s, to check the null space of ˆ J_s and J^T_s . One main point that the author highlights is the relation between local minima and unrealizable image feature motions. Over the years many hybrid techniques have been developed. These involve computing partial/complete pose from Epipolar Geometry using multiple views or multiple cameras. The values are obtained by direct estimation or through a learning or a statistical scheme. While others have used a switching approach that changes between image-based and position-based on a Lyapnov function. The early hybrid techniques that used a combination of image-based and pose-based (2D and 3D information) approaches for servoing required either a full or partial model of the object in order to extract the pose information and used a variety of techniques to extract the motion information from the image. used an affine motion model from the image motion in addition to a rough polyhedral CAD model to extract the object pose with respect to the camera to be able to servo onto the object (on the lines of PBVS). 2-1/2-D visual servoing developed by Malis et al. is a well known technique that breaks down the information required for servoing into an organized fashion which decouples rotations and translations. The papers assume that the desired pose is known a priori. The rotational information is obtained from partial pose estimation, a homography, (essentially 3D information) giving an axis of rotation and the angle (by computing the eigenvalues and eigenvectors of the homography). The translational information is obtained from the image directly by tracking a set of feature points. The only conditions being that the feature points being tracked never leave the field of view and that a depth estimate be predetermined by some off-line technique. 2-1/2-D servoing has been shown to be more stable than the techniques that preceded it. Another interesting observation with this formulation is that the authors claim that the visual Jacobian will have no singularities during the motions. The hybrid technique developed by Corke and Hutchinson, popularly called portioned approach partitions the visual (or image) Jacobian into motions (both rotations and translations) relating X and Y axes and motions related to the Z axis. outlines the technique, to break out columns of the visual Jacobian that correspond to the Z axis translation and rotation (namely, the third and sixth columns). The partitioned approach is shown to handle the Chaumette Conundrum discussed in. This technique requires a good depth estimate in order to function properly. outlines a hybrid approach where the servoing task is split into two, namely main and secondary. The main task is keep the features of interest within the field of view. While the secondary task is to mark a fixation point and use it as a reference to bring the camera to the desired pose. The technique does need a depth estimate from an off-line procedure. The paper discusses two examples for which depth estimates are obtained from robot odometry and by assuming that all

Sorenson Squeeze

KoalaPad

Opponent process

Plotly

Visual servoing

KoalaPad

Related Articles