[{"slug":"widp-2023","title":"Waar is de Pinguin 2023","featured":true,"creationDate":"2022-04-01","category":"Project","excerpt":"Originally planned for 2020 but delayed due to COVID, the third iteration of Waar is de Pinguin is to be executed in 2023. Waar is de Pinguin is a recurring real-world puzzle race designed in the spirit of the Great Race and the MIT Mystery Hunt. The puzzles combine digital and physical components, and guide participants to reach the final location before any of the other teams do. The extra time allowed for some revisions to the originally planned 2020 puzzle mechanics and additional surprises.","labels":[{"id":"geo","name":"Geo"},{"id":"widp","name":"WIDP"}],"cover":"widp-2023.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/widp-2023"},{"slug":"widp-2019","title":"Waar is de Pinguin 2019","featured":false,"creationDate":"2019-04-01","category":"Project","excerpt":"Waar is de Pinguin is a recurring real-world puzzle race designed in the spirit of the Great Race and the MIT Mystery Hunt. The puzzles combine digital and physical components, and guide participants to reach the final location before any of the other teams do. This instance started with a live broadcast and ended up leading participants to Cologne, Germany.","labels":[{"id":"geo","name":"Geo"},{"id":"widp","name":"WIDP"}],"cover":"widp-2019.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/widp-2019"},{"slug":"widp-2018","title":"Waar is de Pinguin 2018","featured":false,"creationDate":"2018-04-01","category":"Project","excerpt":"Waar is de Pinguin is a real-world puzzle race designed in the spirit of the Great Race and the MIT Mystery Hunt. The puzzles combine digital and physical components, and guide participants to reach the final location before any of the other teams do. In this first iteration, participants ended up exploring Utrecht, the Netherlands, facing a Twitch-Plays-like remote-controlled robot, and other real-world challenges.","labels":[{"id":"geo","name":"Geo"},{"id":"widp","name":"WIDP"}],"cover":"widp-2018.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/widp-2018"},{"slug":"hottarget","title":"Hot Target Detection","featured":true,"creationDate":"2016-10-01","category":"Project","excerpt":"Hot targets such as wildfires and volcanoes have a devastating impact on the planet, our infrastructure, and health. Detecting hot targets early and monitoring their progress is important to successfully manage and control them. Studies have shown that wildfires can be detected in Landsat 8 imagery by using Top of Atmosphere (TOA) reflectance, but false alarms are frequent. In this project, I took a deep neural network approach to hot target detection in satellite imagery.","labels":[{"id":"research","name":"Research"},{"id":"machinelearning","name":"Machine Learning"},{"id":"geo","name":"Geo"},{"id":"ipcv","name":"Image Processing"}],"cover":"hottarget.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/hottarget"},{"slug":"groundcover","title":"Ground Cover Analysis","featured":true,"creationDate":"2016-09-01","category":"Project","excerpt":"Ground cover analysis is used in smart agriculture applications to enable automatic treatment of crops, for instance by finding an optimal distribution of water or pesticide administration. This is especially helpful for farms located in third world countries, that have little access to high-tech machinery and a lot to gain in terms of crop yield. In this project, various methods of ground cover analysis were tested to help farmers in the Bangladesh delta cultivate their land.","labels":[{"id":"research","name":"Research"},{"id":"machinelearning","name":"Machine Learning"},{"id":"geo","name":"Geo"},{"id":"ipcv","name":"Image Processing"}],"cover":"groundcover.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/groundcover"},{"slug":"aves","title":"AVES","featured":false,"creationDate":"2016-01-01","category":"Project","excerpt":"AVES is a video search application created to evaluate relevance feedback in multimedia retrieval systems, for an internship at TNO. The engine uses deep learned neural networks to detect concepts, and is based on the TNO-VIREO, and UTWENTE-PRFUBE systems. It incorporates a novel Rocchio-like relevance feedback algorithm to boost retrieval results, outperforming state of the art reranking algorithms.","labels":[{"id":"research","name":"Research"},{"id":"ipcv","name":"Image Processing"}],"cover":"aves.jpg","html":"

Introduction

Relevance feedback, the application of human feedback regarding the performance of information retrieval systems, has been a topic of study in the field of information retrieval for almost 50 years. Starting with textual document retrieval, the field has since expanded to (content-based) multimedia retrieval (such as audio, images, and video) as well. In the current decade, we are confronted with more and more multimedia content. The high rate at which open sensor networks are being set up and increasing rate at which sensor data is available today expose the need to perform semantic searches over these large heterogeneous datasets.

One of the challenges this brings is bridging the semantic gap, the discrepancy between the high level query posed by the user in natural language, and the low level sensor data features. One way of decreasing this gap is to include the user in the information retrieval system. To identify what the user is looking for, the system can iterate a number of times over its results, using the users feedback on which returned results are relevant for its query and which results are irrelevant. Adapting to the user's feedback, the system can refine the search query and retrieve more relevant results.

In the last years, relevance feedback in information retrieval is an increasingly active field of research. In this section we will give a brief overview of the status quo. One of the most well-known and applied relevance feedback algorithms that has its origins in text-retrieval is the Rocchio algorithm. The classic Rocchio algorithm of relevance feedback looks to find the most optimal query based on the user's initial query, and relevance feedback consisting of positive and negative documents. This method of relevance retrieval found its way from text-retrieval into many other domains, including video retrieval.

Relevance feedback can be performed automatically, without any user interaction, or manually, by allowing a user to mark results as relevant or not relevant in varying degrees. The first branch of relevance feedback, also called pseudo-relevance feedback, has piqued the interest of a large number of researchers and software engineers due to its non-reliance on users, though normal relevance feedback is also very relevant to this day. Whereas in normal relevance feedback the user would have to iterate over the retrieved results a number of times, this does not have to be the case in a (well performing) pseudo-relevance feedback system. This makes it favourable for implementation since often the user does not have the time or motivation to give extensive feedback. Human relevance feedback has been known to provide major improvements in precision for information retrieval system.

Research

In this research we evaluated a novel method of multimedia retrieval that incorporates relevance feedback using concept detector weight calibration. The method proposed in this research (AVES) is based on work by Rocchio. Rocchio has been proven to be a strong method of relevance feedback for text-retrieval and we believe the application for multimedia retrieval purposes is promising and worth investigating. We simulated user relevance feedback (optimal-, pseudo-, and random-relevance feedback) to evaluate the model's performance. We also evaluated the model's performance using human relevance feedback. Retrieval without relevance feedback is taken as a baseline, and the well-performing RS method is used for comparison. Giacinto and Roli introduced this method - that takes into account not only a document's relevance towards the other documents, which is usually considered, but also its irrelevance. The formula they utilize of a document's relevance takes the inverse of a documents distance to the nearest relevant document over the distance to the nearest irrelevant document (see Equation 1.1 below). This score, named relevance score (RS), is then used as ranking measure.

$\n\\begin{equation}\n\\begin{align}\n RS(I) = (1+\\frac{dR(I)}{dNR(I)})^{-1}\\text{, with} \\tag{1.1} \\nonumber \\newline \n I = \\text{Image} \\nonumber \\newline\n dR = \\text{Dissimilarity from nearest image in R} \\nonumber \\newline\n dNR = \\text{Dissimilarity from nearest image in NR} \\nonumber \\newline\n R = \\text{Set of relevant videos} \\nonumber \\newline\n NR = \\text{Set of nonrelevant videos} \\nonumber\n\\end{align}\n\\end{equation}\n$

Implementation

The current implementation has been dubbed AVES (Automatic Video Event Search). The system is setup as a Python app using Flask (a lightweight web framework based on Werkzeug and Jinja2). To render the pages it uses Blueprints and a number of small (optimization/minification) tools for static asset preprocessing. This is set up as a Gulp pipeline. Nunjucks is used as templating engine and SocketIO provides a way for the app to communicate changes to and from the backend quickly over websockets.

Initial ranking

Relevance feedback and reranking

Method

Results

Conclusion

References

[1] Zhou, Xiang Sean and Huang, Thomas S, "Relevance feedback in image retrieval: A comprehensive review", Multimedia systems, vol. 8, no. 6, pp. 536-544, Springer, 2003.

[2] Rocchio, Joseph John. "Relevance feedback in information retrieval." (1971). 313-323.

[3] Gia, Giorgio, and Fabio Roli. "Instance-based relevance feedback for image retrieval." Advances in neural information processing systems. 2004.

\n","readingTime":"5 min read","fullURL":"https://pingen.dev/projects/aves"},{"slug":"dasbot","title":"StarCraft Bot","featured":false,"creationDate":"2015-12-01","category":"Project","excerpt":"Strategy recognition and counter-strategy generation are of vital importance in realtime strategy games. In this research a StarCraft Brood War bot was designed and tested that uses a neural network to learn optimal counter strategies with features extracted from game replays.","labels":[{"id":"research","name":"Research"},{"id":"machinelearning","name":"Machine Learning"}],"cover":"dasbot.jpg","html":"

Introduction

StarCraft: BroodWar (1999) is the expansion set of the game Starcraft (1998), developed by Blizzard Entertainment. It is a Real-Time Strategy (RTS) game, and considered to be, not just in its own genre, a major influence on gaming. The franchise is listed twice (StarCraft, including the expansion, and its successor StarCraft 2, released in 2010) in the top selling PC games of all time, making apparent its relevance even today.

In multiplayer mode, players are required to build a base using harvested resources, build an army, and destroy the opponent player's base with that army. A player is victorious when there are no enemy buildings left in the game. Being an old - but well known strategic game, it lends itself exceptionally well for research purposes. Not only is there a vast number of replays to be analyzed, it also runs smoothly on any modern computer setup. This allows for automated tournaments to be held online versus different automated agents.

The focus of this project was to implement such an automated agent using a model for strategy prediction that relied on data mined from replays. The main heuristic used to select counter strategies was a time-optimal counter score calculated by a number of different offensive and defensive features.

Competitive StarCraft

Although the best StarCraft game AI's cannot yet outperform expert human players, the competition grows stronger every year. One of the main stages for those game AI's (or bots) are automated tournaments. Currently, the three largest tournaments of this kind are the Artifcial Intelligence and Interactive Digital Entertainment (AIIDE), the IEEE Computer Intelligence and Games (CIG), and the Student Starcraft AI (SSCAI) competitions. In these tournaments competetors can submit their bots, after which a set number of games will be played,pairing each bot against eachother via LAN.

Research

Weber et al. (2009) have used data mined from replays to predict strategies and develop an opponent model. Their results show that machine learning algorithms can be used to successfully predict strategies with 69% precision 5 minutes into the game, growing to 86% at 10 minutes (using NNge, or non-nested generalized exemplars). Using a rule set to classify tier 2 (or mid-game) strategies, they labeled their replay data based on domain knowledge.

Synnaeve & Bessiere (2011) have also made progress in the area of Bayesian networks\napplied to build order prediction, and reactive build order construction. In one study they computed the distribution of build orders and applied a Bayesian network to generate an estimate of a players build order based on the observed game state. Prediction results were shown to be as high as 4 buildings ahead of a current game state, dropping to 3 when a 0.3 random noise ratio was applied to simulate a competitive setup.

Bot Overview

The bot performed in a highly modular fashion, as is common in these types of bots (although a holistic approach has been attempted in RTS games - however none as complex as StarCraft). This modularity allows it to break down the problem of winning a game into seperate subproblems and deal with them individually. To achieve this, a number of managers were implemented, each handling a different aspect of the game.

$\"Figure$

Figure 1. A modular overview of the managers in the bot. Solid arrows indicate control, whereas dashed lines indicate data flow. Managers within a column also have data flow connections though they are not shown here.

The most important managers are the Build Manager; the Macro Manager; the Micro Manager; the Scout Manager; and the Strategy Manager.

Features

Various features were implemented for each of these managers, such as an extensive build- and economy planner for the build/macro manager (responsible for base and worker construction, and resource harvesting); a squad system to optimize army movement and unit positioning, and a potential field implementation of target acquisition for the micro manager; a system to indicate optimal time and location for the scout manager; and finally the neural network based model for counter strategy selection for the strategy manager.

$\"Figure$

Figure 2. Overview of the three different potential field implementations. The Global Field is the top layer and represents the difference between walkable and nonwalkable tiles, shown here in green and black respectively. The Squad Field shows a group of Dragoons attacking some Drones, wanting to move in attack range (green), and getting repelled a bit by eachother (red area). The bottom image shows a set of Personal Fields, two of which have been reversed as a consequence of the unit having their cooldown activated.

Data

A set of 24552 Protoss versus Protoss (or PvP) replays were gathered from the website bwreplays, which was reduced to a number of 24485 (99.727% of the original dataset) after pruning some faulty or otherwise unusable replays. To enable modeling of the various strategies (or build orders) that exist in the game, only PvP matchups were considered. The reason for\nthis is twofold. Firstly, the bot was created to play the Protoss race. Hence replays including Protoss players. Secondly, choosing the option to consider mirror-matchups only means a separate Strategy Tree for the opponent race does not have to be created. It is expected that results from this project can be applied to different races as well; taken into account that separate Strategy Trees are produced from those replays.

The dataset contains replays by 11984 unique players, both from individual games and tournament settings. Spanning from 1999 to 2013, and versions 1.08 to 1.16.1 (current) of the game, it covers the game's entire lifetime. This enabled modeling of older, though maybe not used as often, strategies as well.

Together with the creation of the Strategy Tree, a database was created to log all the data regarding offensive and defensive power for each player according to the feature set and the id of the winning player, per replay. These values were also stored in the Strategy Tree, but they were stored in a separate database because they are used separately in training the neural network.

Since only offensive and defensive values were used for the current meta-game (they may have been altered in patching throughout the years) to determine a counter-strategy, only replays from the current patch (1.16.1) were taken into account. This means that the training set contained a total of 10889 entries (44.472% of the original pruned dataset).

Strategy Tree

The Strategy Tree is a hierarchical tree ADT on which nodes represent a distinct choice in build order. This could be the construction of a Forge (a Protoss building that unlocks the construction of static defences), or the researching of an upgrade. The race's main building will be represented as the root node, since this is the building every player starts off with and it is always present when the game begins.

From there on out it branches into the different decisions in build order a player has made. Each path in the tree then represents a strategy for that race, and the entire tree is a model for all the strategies observed in the replays.

For every replay parsed, basic information on the player names and id's, the winning player, and offensive and defensive power for both players is stored. The replay is then fed into a tree generating module, which gathers data on the build orders from both players. It will traverse through the existing tree,\nstarting at the root node, and go down a path if the actions of the build order from the replay match the ones found in the tree. If it cannot find an existing path, it will create a new branch. The likelihood of a specific branch is also updated. This value represents the average ratio of a node being visited compared to its siblings.

In theory, the Strategy Tree could grow infinitely large. However, since the tree is generated based on real-life replays this is not the case. All paths in the tree represent a build order executed in a live match, or a subset of one such replay. There are a number of game decisions not included in the tree as nodes, such as Pylons, Assimilators, and Photon Cannons.

The final element of the Strategy Tree is the set of values for the offensive and defensive power stored in a node. These values represent the ability of the strategy to combat its opponent, either by striking at them or by defending from an attack. Offensive power is dependent on the combined raw attack power of the units present, the number of attack upgrades researched, and the number of unit-producing structures. Defensive power is dependent on the combined raw armour power of the units present, the number of defence upgrades researched, the number of static defences, and the number of worker units (as an indication of resource income).

$\"Figure$

Figure 3. Building the Strategy Tree. A build order gathered from the parsed replay is added to the existing tree by traversing its nodes until no existing path can be found. The existing branch is then continued until the entire build order is represented in the Strategy Tree.

Strategy Recognition

Once the Strategy Tree has been generated, it can be serialized and used by the bot in the Strategy Manager. Whenever the Scout Manager gains new information on the status of the opponent, the Strategy Tree is used to make an assessment on what strategy the opponent is pursuing. A list of currently observed opponent units and upgrades is fed into the Strategy Tree model, and returned is a set of paths that contain the observed build order. For example, when a Nexus and Gateway are observed, a list of paths containing this subset is returned. From that list the smallest option is selected, meaning that a path of lesser length still containing the observed subset is preferred over options of bigger length. An observation can match two separately returned paths at the same time. The recognition of an enemy's position in the tree is obviously dependent on the validity of scouted information.

Strategy Generation

A neural network trained on the value of the winning player was applied with a supervised learning paradigm using the Encog framework, and tested with 5-fold cross validation (to allow it to train in the same environment as the\nbot and strategy model). The network consists of 15 input neurons (7 offensive/defensive features for each player -as listed above-, and the total iteration count), 2 hidden neurons, two output neurons, and two bias neurons. The bias neurons are set to random values in the range of [0.3, 0.7].

The neural network was able to predict a winner of a match given these input features with a validation error stabilizing at a mean of 0.2115 over the last 2000 iterations, meaning classification of about 78% of the replays to their correct output (win or loss condition).

The weights learned by the network were then applied to the bot and utilized in its Strategy selection model.

$\"Figure$

Figure 4. Error plotted against the number of epochs of the 5-fold cross-validation testing, stabilising at a mean of 0.2115 over the last 2000 epochs. The light blue plot is the original plot per epoch; The dark blue plot is a plot averaging every 10 epochs; The red plot is a plot averaging every 100 epochs.

References

[1] Weber, B. G. and Mateas, M. (2009) A data mining approach to strategy prediction. Lanzi, pp. 140-147.

[2] Synnaeve, G. and Bessiere, P. (2011) A bayesian model for opening prediction in rts games with application to starcraft. Cho et al., pp. 281-288.

\n","readingTime":"11 min read","fullURL":"https://pingen.dev/projects/dasbot"},{"slug":"guiderobot","title":"Guide Robot","featured":false,"creationDate":"2015-11-01","category":"Project","excerpt":"This project was aimed at researching the effects of head rotation and audiovisual feedback in guide robot behaviour. A robot was constructed for the purpose of guiding small groups of people around in an unfamiliar area. This research was conducted as part of the EU-funded SPENCER project (600877).","labels":[{"id":"research","name":"Research"},{"id":"ux","name":"UX"}],"cover":"guiderobot.jpg","html":"

Introduction

Handling transferring passengers efficiently poses a significant challenge in the commercial aerospace business. In 2013, the number of transfer passengers at Amsterdam Airport Schiphol - the largest airport in the Netherlands - rose to 22 million, totalling more than 40% of all passengers. It is clear that managing this massive migration of people effectively is of benefit for both the passengers as well as airliners. Passengers may get lost, have trouble finding their gate, or run into language barriers. This is just as small set of reasons for flights to be seriously delayed, and passengers missing their connecting flights.

A guide robot could be of help to passengers in need of assistance with finding their way around the airport, and it is exactly this purpose for which the SPENCER project was instigated. This EU funded project is doing research on the implementation of a robot platform that will be able to guide groups of transferring passengers at airport hubs, and by doing so decrease the current transfer time.

Research

As part of this project it was the aim of this study to research the optimal behaviour of a guide robot, most notably in a crowded space such as an airport terminal. The interest of the study was to research the effect of head rotation and audiovisual feedback in guide robot behaviour.

In agreement with results from Butler & Agah (2001), Joosse et al. (2014) found in their research on Human-robot interaction performed with Chinese, American (US) and Argentine participants that, across cultures, users prefer a robot not to enter their personal space. Partially in accordance with previous studies on cultural differences in human interaction it was found that in the high-contact condition of Chinese participants, a closer approach was perceived as more comfortable. Argentinian participants however, though being a high-contact culture as well, responded more similarly to participants from the US, which favoured a less close approach. This could be due to Argentina being a relatively individualistic country compared to other South American countries. Participants found it more appropriate when the robot positioned itself between the mother and child in a triangular setup of mother-father-child with the robot approaching the group, than between the father and child. This could be attributed to the robot facing the father (alpha actor). This was taken into account in designing the robot's locomotor behaviour.

Shiomi et al. (2010) performed a guide robot experiment in the field in an attempt to attract more bystanders into overhearing its conversation, and thereby spontaneously participating in the tour. In the experiment, a guide robot was set up to greet, guide, and give advertising information to groups of people in a shopping mall. Results indicated that participants listened more when the robot was travelling backwards and\nthat it attracted more bystanders to listen in, though the ratio of people being guided might be higher in the forward condition. This effect may be explained due to the area of audience being in front of the robot in\nthe forward condition, meaning bystanders that are opposite to the robots movement direction have a hard time entering the area of audience. In contrast, when the robot is driving backwards, the area of audience is turned towards the group. This means that bystanders coming from behind the guiding robot can more easily enter the area of audience. Since airport guide robots should exhibit the same kind of behaviour as the tour robot in this study it was implemented, though care was taken to ensure that the rate of people arriving at the intended destination remains high enough, since attracting people should not be a top priority.

Robot platform

The mobile robot system used was a Festo Didactic Robotino v2.0. On top of the base system an MDF platform was constructed to attach the outer shell, putting the robot's total height at 170cm. This shell, which was made up of a metal frame and a combination of plastic and synthetic material, held a tablet which was used to display output to, and receive input from, the user.

Hardware

The platform's hardware components included a stainless steel chassis where the power supply, the drive module (3 independent omnidirectional drive units mounted at a 120 degree angle to one another) and the distance and bumper sensors were located. On top of that a command bridge where the controller and I/O module were located;

$\"Figure$

Figure 1. Robot plaform interior diagram.

Software

The code running on the controller unit reads odometry data from the motors and Com (Command Bridge), and measures the distance travelled. The motors output the x/y coordinates with respect to origin. This data is sent through a socket to a TCP client running on the tablet, where the remaining distance is displayed after some post-calculations. Voice generation and recognition is done using the Google Android Speech library, relying on keyword recognition.

Experiment

A between-subject study was performed with 25 participants to test the effects of robot head direction and rotation. The robot would guide groups of up to 3 people around an unfamiliar area at the University of Twente in different head rotation conditions accompanied by brief verbal dialog. Another iteration of the experiment (N=19) tested the optimal modality of audio-visual feedback during the guiding process.

Questionnaire results together with comment and video analysis revealed that participants evaluated the robot facing them and driving backwards as unnatural and intimidating. If information relating to the guide process is shown, backwards locomotion is rated more favourably. Furthermore, participants much preferred touch input to voice as a desirable way of interaction with the robot.

$\"Figure$

Figure 2. Participants engaging with the robot.

References

[1] Schiphol. (2014) Transport and traffic statistics. Schiphol.

[2] Spencer. (2011) European research project: Cognitive systems and robotics. Spencer.

[3] H. Hicheur, S. Vieilledent, and A. Berthoz, "Head motion in humans alternating between straight and curved walking path: combination of stabilizing and anticipatory orienting mechanisms", Neuroscience letters, vol. 383, no. 1, pp. 87-92, 2005.

[4] J. T. Butler and A. Agah, "Psychological effects of behavior patterns of a mobile personal robot", Autonomous Robots, vol. 10, no. 2, pp. 185-202, 2001.

[5] M. P. Joosse, R. W. Poppe, M. Lohse, and V. Evers, "Cultural differences in how an engagement-seeking robot should approach a group of people", in Proceedings of the 5th ACM international conference on Collaboration across boundaries: culture, distance & technology. ACM, 2014, pp. 121-130.

[6] M. Lohse, N. van Berkel, E. M. van Dijk, M. P. Joosse, D. E. Karreman, and V. Evers, "The innfuence of approach speed and functional noise on users' perception of a robot", in Intelligent Robots and Systems (IROS), 2013 IEEE/RSJ International Conference on. IEEE, 2013, pp. 1670-1675.

[7] M. Shiomi, T. Kanda, H. Ishiguro, and N. Hagita, "A larger audience, please!: encouraging people to listen to a guide robot", in Proceedings of the 5th ACM/IEEE international conference on Human-robot interaction. IEEE Press, 2010, pp. 31-38.

[8] K. M. Lee, W. Peng, S.-A. Jin, and C. Yan, "Can robots manifest personality?: An empirical test of personality recognition, social responses, and social presence in human-robot interaction", Journal of communication, vol. 56, no. 4, pp. 754-772, 2006.

\n","readingTime":"7 min read","fullURL":"https://pingen.dev/projects/guiderobot"},{"slug":"ease","title":"Monitoring Panic Attacks","featured":false,"creationDate":"2015-09-01","category":"Project","excerpt":"Panic disorder (PD) can be effectively treated with a variety of interventions, including psychological therapies and medication. In the great majority of cases hyperventilation is involved, exacerbating the effects of the panic attack. Deliberate deep breathing exercises help to rebalance the oxygen and CO2 levels in the blood. The aim of this project was to create a smartwatch app that monitors and aids patients suffering from PD.","labels":[{"id":"research","name":"Research"},{"id":"mobile","name":"Mobile"},{"id":"health","name":"Health"}],"cover":"ease.jpg","html":"

More information to be added.

\n","readingTime":"1 min read","fullURL":"https://pingen.dev/projects/ease"},{"slug":"virtualad","title":"Virtual Advertising","featured":false,"creationDate":"2015-08-01","category":"Project","excerpt":"Many sports events are broadcast on television with an overlay providing extra advertising space. In this computer vision project, virtual banners were placed inside existing clips of sports events using techniques such as line detection, camera auto-calibration, and perspective transforms.","labels":[{"id":"research","name":"Research"},{"id":"ipcv","name":"Image Processing"}],"cover":"virtualad.jpg","html":"

Introduction

An important aspect of image processing and computer vision is finding vanishing lines for calibration of a camera using these vanishing lines. For this project, we took a look at vanishing lines and in video clips of tennis and soccer games. The aim was to project a banner in the original video clips, transformed so that it looks like it is actually on the field. This means the static image resources need to be updated every frame to account for changes in camera position. We first take a closer look at edge detection techniques.

Edge detection

To detect objects and other interesting variation in an image, we can apply edge detection. There are many methods for this, but most are search-based or zero-crossing based. Search-based methods find edges by calculating edge strength (ie. by using the gradient magnitude), and then searching for local directional maxima of the gradient magnitude. Zero-crossing based methods look for zero-crossings (the point where the sign of a mathematical function changes, from positive to negative or vice versa) in second-order derivatives (ie. the Laplacian) of the image.

Two classic methods zero-crossing based edge detection methods are Marr-Hildreth, and Canny. Marr-Hildreth, the older method, introduces the concept of edge detection with the following process: First, the image is convolved with the Laplacian of the Gaussian. Then to find the edges zero crossings are found in the filtered result. This approach can generate false edges, and depending on your dataset, Canny detection might be a better option. Canny edge detection works as follows: it also first starts with a Gaussian filter, and next, the image's intensity gradient is found. Then, with non-maximum suppresion and hysteresis thresholding the final detection of edges is done. Canny, despite its age, is still state-of-the-art. Not many other edge detectors perform significantly better without large drawbacks.

$\"Figure$

Figure 1. Canny edge detection applied to an image

Strategy

The placement and projection of a virtual advertisement is based on a couple of aspects:

The 3D localization of the side lines of the game with respect to the arbitrarily chosen world coordinate system.
The position and orientation of the camera with respect to this world coordinate system.
The intrinsic parameters of the camera.

Since there were no specific calibration objects in the scene, the court lines of the field, and its known lengths, are used. In computer vision this falls under the umbrella of auto-calibration (self-calibration). See, for instance, Zhang et al. and Orghidan et al.

We chose some sample clips from tennis matches in which the (orthogonal) court lines were sufficiently visible during the panning, rotation, and zooming of the camera. Then, the lines were located using Canny edge detection.

A Hough transform is applied to the resulting binary edge map to obtain an accumulator transform matrix, including theta and rho values for the detected lines. Theta is the angle of that perpendicular vector in degrees ranging from -90 to 90 degrees. The peaks of the transform are then found, and the line segments are retrieved through the edge map and Hough output.

Gap filling and maximum length for line segments are implemented to restrict this selection. Lines are tracked across frames, and the parameters of the detected lines were then used to calibrate the camera. Using the calibration paramters we can then project a virtual banner near a court line. Figure 2 shows this line tracking and advertisement placement for the tennis video.

$\"Figure$

Figure 2. Line tracking and ad placement in a tennis match

We then applied this method to other videos, including one of a football match. Due to the larger variety in camera changes (zooming, large movements) in football matches versus tennis matches, this was a harder case. Figure 3 shows some results.

$\"Figure$

Figure 3. Visualization of placement of 8 banners. The edge map is shown on the left side, and the final image with banner projections is shown on the right side. The top four are vertical banners; the four placed on the field are horizontal banners angled at 60 degrees

References

[1] Z. Zhang, "Camera Calibration", Emerging Topics in Computer Vision, G. Medioni and S. B. Kang, Eds., ed: Prentice Hall Professional Technical Reference, 2004, pp. 4-43.

[2] R. Orghidan, J. Salvi, M. Gordan, and B. Orza, "Camera calibration using two or three vanishing points", Computer Science and Information Systems (FedCSIS), 2012 Federated Conference on, 2012, pp. 123-130.

[3] Beardsley, Paul, and David Murray. "Camera calibration using vanishing points." BMVC92. Springer London, 1992. 416-425.

[4] Canny, John. "A computational approach to edge detection." Pattern Analysis and Machine Intelligence, IEEE Transactions on 6 (1986): 679-698.

[5] Ding, Lijun, and Ardeshir Goshtasby. "On the Canny edge detector." Pattern Recognition 34.3 (2001): 721-725.

[6] Lv, Fengjun, Tao Zhao, and Ram Nevatia. "Self-calibration of a camera from video of a walking human." Pattern Recognition, 2002. Proceedings. 16th International Conference on. Vol. 1. IEEE, 2002.

[7] Marr, David, and Ellen Hildreth. "Theory of edge detection." Proceedings of the Royal Society of London B: Biological Sciences 207.1167 (1980): 187-217.

[8] Sharifi, Mohsen, Mahmoud Fathy, and Maryam Tayefeh Mahmoudi. "A classified and comparative study of edge detection algorithms." Information Technology: Coding and Computing, 2002. Proceedings. International Conference on. IEEE, 2002.

\n","readingTime":"6 min read","fullURL":"https://pingen.dev/projects/virtualad"},{"slug":"grawe","title":"Grawe/Graaf","featured":false,"creationDate":"2015-07-01","category":"Project","excerpt":"Grawe is an aggregated search webpage made to showcase various implementations of (non-)blended search result retrieval. Graaf added to that by making the Dutch part of Wikipedia more accessible to children between ages 9-12.","labels":[{"id":"research","name":"Research"},{"id":"ux","name":"UX"}],"cover":"grawe.jpg","html":"

Introduction

Helping young users search for information on the web is a big challenge for the field of Information Retrieval. Young users of search engines experience difficulty searching for the information they wish to access, especially children aged 12 and lower. More than 60% of children between 9 and 12 years old report needing help from time to time with information acquisition, and this number grows to 90% in children between 5 and 8 years old. Observed shorter average query length together with larger usage of natural language indicate that the use of keywords to generate a specific query is a problem in this target group.

Children's queries have an informational intent, i.e. children query a search engine for information about topics that they assume are available on the web. This in contrast to an adult's queries, which have a more transactional intent. It has been observed that children, in their search with an informational intent, often start reading a result's page from top to finish. They do not exhibit the scanning behaviour that is often seen in adults.

A system that highlights parts of information especially relevant to the child's query can be of use to these children in guiding them to the information they want. Wikipedia is a major source of information for Dutch school children. However, due to a lack of proficiency in scanning a piece of text for relevant information, children will often start to read the Wikipedia article at the top of the page, and continue reading until the information is found. Wikipedia articles contain large portions of text and other content that are not relevant to the specific query, possibly overwhelming a child with information. Children's search behaviour with an informational intent could therefore be improved by providing a system that directs them to those parts of the article's content that are most relevant to the query. The aim of this research was to measure the effects of a new Wikipedia browsing system aimed at children on information retrieval performance.

Grawe

To test this hypothesis a search engine named Grawe (which means 'to dig' in Afrikaans) was developed that aggregated results from a number of different sources (Google, Bing, Youtube, Wikipedia StackOverflow, Tumblr, GitHub, Vimeo, Reddit, Flickr, Nature, and Yummly). These were then ranked and displayed in a list of items based on query relevance. Some features of this basic search engine include a category labeling based on returned results; favicon retrieval; url abbreviation (fully shown on mouseover) for readability; result bundling (ie. 'More results from [domain]..'); and a quick info box for Wikipedia results, recipies, and StackOverflow questions.

$\"Figure$

Figure 1. Left: Overview of the different features in the Grawe search engine on a sample query. Right: Example view of the StackOverflow quickinfo box on a sample query.

Graaf

The Grawe engine was used as a basis for the design of two versions of a Wikipedia browsing system (dubbed Graaf, the Dutch word for 'dig'). The first being almost exactly a copy of Grawe, but only returning Dutch Wikipedia results this time. The other version was the enhanced browsing structure. Upon entering a query, users would immediately be served with a Wikipedia page (eliminating the need to select the best result out of a list, which is reported to be a problem for young users).

A non-standard, enlarged font to increase readability was chosen to display the content. Tables relating to meta-info and auxiliary content such as edit-links are then stripped. Images are kept, but always displayed on the right side of the textual content. The most eye-catching feature is the highlighting feature. The initial query is first stripped of common words (because of children's heavy reliance on natural language in queries), and an iterator function is then called to find all sentences that contain at least 75% of the remaining keywords and highlight those in a yellow hue. An additional synonym highlighting in blue is applied to find and mark synonyms of words commonly used in informational queries. For example 'big', 'large', and 'size' might by synonyms since a user may search for 'how big is the moon', but also 'how large is the moon', or 'what is the size of the moon'. This highlighting was implemented to guide the vision of the user to relevant parts of the text, and\nthe page would automatically jump to the first piece of highlighted text firstly to a highlighted sentence if available, then to a synonym).

The sidebar functions as a scrollbar, with the additional feature of having a visual overview of where in the text you are currently positioned. It was implemented to aid in maintaining the broader picture of an article's structure, as well as being able to see any other highlighted sentences further down on the page more quickly. A minor feature is the horizontal list of suggestions of other articles at the top of the page. This was implemented to provide the user with suggestions of what else to search for, but also to grant some feedback on the search query. Finally, a dictionary was implemented to help users with understanding difficult terms. Every page was parsed by utilizing the Wizenoze API, after which difficult terms could be identified and easier synonyms supplied.

$\"Figure$

Figure 2. Overview of the different features in the Graaf search engine on a sample query.

Experiment

A primary school cooperative was enthousiastic to let their students work with the engine, thus enabling thorough testing of the new browsing system. Children of classes 6, 7, and 8 aged between 9 and 13 were tested using the engine. A list of questions was provided for the children, such as 'What was the name of the volcano that erupted in Iceland in 2008 that disrupted a lot of air trafgfic?'. These questions were designed, together with the school teachers, to be easy enough for the children to know what the topic was about, but not too easy for them to know the answer right away (forcing them to use the search engine to find the answer). Children would choose a random question as a starting position, after which they would have 10 minutes to look up the answer to as many questions as they could do in the given timeframe.

Results indicated that the enhanced structure yielded a 40 second improvement in lookup time (158.9s versus 110.8, N=24, p=0.068) per question. More questions were answered in the same timeframe in condition with the enhanced browsing structure. Accuracy is also better in the enhanced structure condition, as students in that group answered more questions correctly.

$\"Figure$

Figure 3. Left: Mean lookup time per condition, and average amount of questions answered per condition. Right: Answer accuracy for the first two questions respectively.

References

[1] Gossen, T., Low, T., & Nürnberger, A. (2011, July). What are the real differences of children's and adults' web search. In Proceedings of the 34th international ACM SIGIR conference on Research and development in Information Retrieval (pp. 1115-1116). ACM.

[2] Gossen, T., & NüRnberger, A. (2013). Specifics of information retrieval for young users: A survey. Information Processing & Management, 49(4), 739-756.

[3] Duarte Torres, S., Weber, I., & Hiemstra, D. (2014). Analysis of search and browsing behavior of young users on the web. ACM Transactions on the Web (TWEB), 8(2), 7.

\n","readingTime":"7 min read","fullURL":"https://pingen.dev/projects/grawe"},{"slug":"peoplestreams","title":"Tracking People Streams","featured":false,"creationDate":"2015-06-01","category":"Project","excerpt":"During large scale events, e.g. pop concerts or busy places like railwaystaions, large numers of people pass eachother very closely. In order to direct these streams of people or in case of emergency to send help in the quickest way and direct these masses of people to exits, it is important to track such streams and recognize behavioural patterns.","labels":[{"id":"research","name":"Research"},{"id":"ipcv","name":"Image Processing"}],"cover":"peoplestreams.jpg","html":"

Introduction

The management and control of large gatherings of people at events, such as festivals, poses significant challenges to public safety. The high density of people at these events can give rise to dangerous situations. Crowd analysis can aid in mitigating the security risks. In these occasions masses of people are monitored by one or more observers and, if necessary, security services are ready to act and redirect them to different areas. However, given the large scale of these situations, an automatic method to detect potentially dangerous phenomenon can be a helpful instrument to support human supervision. The construction of good crowd models can also aid in the design of public spaces, since these should be able to withstand the crowds that are expected to be there.

People stream analysis

Significant effort has already been directed towards crowd and people stream analysis [3] [4] [5], the detection of dangerous or incongruous events [6] [7], and towards the integration of such analysis into a surveillance system [8]. A 2013 review of video analytics of crowded scenes can be found in published work by M. Thida, et al.

Crowd behaviour patterns

Several behaviour patterns like blockings, bottlenecks, rings, fountainheads and lanes were proposed by Solmaz et al., and also adapted by Stijntjes. In their work, they propose a method of automated analysis of crowd behaviour based on optical flow and regions of interest. This method integrates low-level features retrieved from analysing the optical flow field of a scene, with high level information retrieved through the extraction of features by determining a Jacobian in regions of interest. Since it does not require training, or individual analysis of objects in the scene, it might prove useful for on the fly crowd behaviour analysis.

This project is based primarily on previous research done by Solmaz et al., and Stijntjes. Videos of crowded scenes were studied and patterns which may occur and evolve in risky situations were identified: in particular we focussed our attention on bottlenecks and studied them using a method based on optical flow and eigenvalue maps.

Blockings and bottlenecks may indicate obstructions, such as people stumbling, or partially closed off passageways. Fountainheads and ring formations may indicate that there is a potentially dangerous situation or object at the centre of these patterns. The automated early detection of such events can be a major contribution to health and safety services. Not only to guide the large stream of people to safety orderly, but also to rapidly respond to threats or give first aid.

Data

Footage of crowded scenes is easily found on the web, but most of them are registered from moving cameras or change perspective frequently, making them not quite suited for our purposes. In this project, input obtained from a fixed camera is analysed and predefined patterns (bottlenecks) are extracted where possible. To extend the dataset a number of computer generated video sequences have been created using a free software package Pedestrian Dynamics 2. This allows for data creation in a controlled and qualified manner for analysis. The complete dataset on which we tested our implementation therefore consists of our own generated data and an expansion of footage found on the internet.

Method

For a given video sequence, after preprocessing, the optical flow is determined. A Jacobian matrix is calculated for the entire flow field. From this matrix eigenvalue maps are calculated. Finally, relevant sections denoting possible bottleneck features are determined in the eigenvalue map. Sections marked as possible bottlenecks are compared with a ground-truth in order to determine the correctness of the method. We will go into a little more detail for each of these steps now.

Preprocessing

Raw video sequences are converted to grayscale and exported as individual images. Any detectable bottlenecks in the videos are examined by visual inspection and stored as ground truth. Furthermore, the geometric scale (pixels/m) of the video is determined by finding objects in the scene with a known size; this assumes the video is shot top-down. Angled videos (albeit small angles) were used as well. Finally, the input sequences were scaled to a fixed geometric scale of 10px/m. A typical input image is shown in Figure 1a.

$\"Figure$

Figure 1. Detection method sequence.

Optical Flow

Optical flow calculation is done using the Horn and Schunk method. For every 2 consecutive frames the optical flow is calculated, and the mean is taken of the entire sequence of frames. The result is a 2D flow field of vectors that describes the average motion of a pixel spanning the video sequence, as can be seen in Figure 1b. The flow field is adjusted to the frame rate of the video sequence, and its geometric scale. It is then filtered using a median filter with a kernel size of 1x1 meter (10x10 px) to smooth out the flow field and eliminate large local fluctuations or errors. Finally, the flow field is thresholded to omit small (< 10^-5) values which are assumed to be caused by noise. The flow field is visualized by adding a 360 degree colour mapping based on the vector's angle and size (see Figure 1c) to aid in verifying the correctness of the flow field.

Jacobian and Eigenvalue maps

We construct a Jacobian from the optical flow field by considering a continuous dynamical system $w' = F(w)$ , with $w' = [u(w), v(w)]^T$ and $w(t) = [x(t), y(t)]^T$ denoting particle velocities and positions respectively. Areas in which the stability is assessed, $w^*$ , referred to as critical points, are found by satisfying $F(w^*) = 0$ . When taking into account small disturbances and noise $z = w - w^*$ , and using Taylor's theorem this yields $F(w^*+z) = F(w^*)z + H.O.T.$ . If we then consider only the critical points (satisfying $F(w^*) = 0$ ), and disregard the higher order terms, this leaves $z' = J_{F}(w^*)z$ with $J_{F}$ being the Jacobian matrix:

$\nJ_{F} = \n\\begin{bmatrix} \n\\frac{\\delta u}{\\delta x} & \\frac{\\delta u}{\\delta y} \\ \n\\frac{\\delta v}{\\delta x} & \\frac{\\delta v}{\\delta y}\n\\end{bmatrix}\n$

The Jacobian's eigenvalues, trace ( $\\tau$ ), and determinant ( $\\Delta$ ) are computed and used to label regions to types of behaviours with different colours based on the mapping from Solmaz et al. and Stijntjes as depicted in Figure 1d.

Feature detection

A filter mask is applied to the eigenvalue map to retain only the portions relevant to a bottleneck, according to the values in Figure 2. Colours signifying a bottleneck are yellow and cyan in Figure 1d. The relevant portions are retained in a black and white image as can be seen in Figure 1e. Blob detection is then applied at which point we discard blobs smaller than 15x15px (or 1.5m2). This reduces noise based on the assumption that a bottleneck feature would at least be equal to or larger than this size. Blobs in proximity to one another (within 1m) are merged. The process of blob detection and classification runs in a single iteration, therefore there is no change of blobs converging into a single blob (Figure 1f). Detected blobs are then labelled according to their behaviour type (Figure 1g).

$\"Figure$

Figure 2. Labelling of candidate regions. This table is a corrected version of the one used by Stijntjes.

Results

In comparison to our labelled ground truth data we obtain around 80% precision and around 80% accuracy, as can be seen in Figure 3. These scores are displayed relative to the epsilon value in the filter map from Figure 2.

$\"Figure$

Figure 3. Bottleneck detection result metrics.

Conclusion

We see an increase in accuracy compared to Stijntjes et al. and Solmaz et al. Misclassifications can also be seen to rapidly decline for large vales of $\\epsilon$ .

These results also show that for detecting bottlenecks with the fixed geometric scale a suitable and distinct range of values for $\\epsilon$ can be found empirically.

The method of detecting features using binary filters from the colour labels in the eigenvalue maps is simple but not very robust. Especially on a larger number of types and sizes of features more sophisticated methods (e.g. cluster analysis) are required.

References

[1] Solmaz, Berkan, Brian E. Moore, and Mubarak Shah. "Identifying behaviors in crowd scenes using stability analysis for dynamical systems." Pattern Analysis and Machine Intelligence, IEEE Transactions on 34.10 (2012): 2064-2070.

[2] Stijntjes, Ingo. "Assessment of automated crowd behaviour analysis based on optical flow." (2014).

[3] Ali, Saad, and Mubarak Shah. "A lagrangian particle dynamics approach for crowd flow segmentation and stability analysis." Computer Vision and Pattern Recognition, 2007. CVPR'07. IEEE Conference on. IEEE, 2007.

[4] Santoro, Francesco, et al. "Crowd analysis by using optical flow and density based clustering." Signal Processing Conference, 2010 18th European. IEEE, 2010.

[5] Jin, Xiaogang, et al. "Interactive control of large-crowd navigation in virtual environments using vector fields." IEEE Computer Graphics and Applications 6 (2008): 37-46.

[6] Velastin, Sergio A., Boghos A. Boghossian, and Maria Alicia Vicencio-Silva. "A motion-based image processing system for detecting potentially dangerous situations in underground railway stations." Transportation Research Part C: Emerging Technologies 14.2 (2006): 96-113.

[7] Khan, Sultan Daud, et al. "Detecting dominant motion flows and people counting in high density crowds." (2014).

[8] Fradi, Hajer, and Jean-Luc Dugelay. "Towards crowd density-aware video surveillance applications." Information Fusion 24 (2015): 3-15.

[9] Thida, Myo, et al. "A literature review on video analytics of crowded scenes." Intelligent Multimedia Surveillance. Springer Berlin Heidelberg, 2013. 17-36.

\n","readingTime":"9 min read","fullURL":"https://pingen.dev/projects/peoplestreams"},{"slug":"shard","title":"Shard","featured":false,"creationDate":"2015-05-01","category":"Project","excerpt":"Shard is an Android app that lets you broadcast what you're currently listening to on Spotify to all of your friends live. Listen to your favourite music together.","labels":[{"id":"mobile","name":"Mobile"},{"id":"music","name":"Music"}],"cover":"shard.jpg","html":"

Introduction

You're lying in bed, listening to your favourite tunes, chatting with that special someone living far away. You want to share that moment. Be in sync with one another and connect through music.

Your favourite player is just warming up for the big match. The stakes are high. The tension in the stadium is tangible, pressing even. To get ready he puts on that one track. His track. Your track. You are ready. Connect through music.

These are just two examples of the idea behind Shard. The app lets you broadcast what you're your currently streaming in Spotify to all of your contacts. The status of your player (playing, pausing, skipping ahead) will be sent to all those listening to your feed live. This project was done mainly to play around with the new Spotify Android API and served as a personal introduction into programming for Android.

$\"Figure$

Figure 1. Shard logo.

Overview

The app features a general register/login portal where users fill in profile details such as their name, email address, and phone number. SMS (text message) verification is built in to ensure users fill in correct account details. When they are first logged in, authentication with Spotify is set up through Spotify's web API. This enables the app to access certain Spotify user data needed to function properly. Users require a Premium Spotify subscription to broadcast their status, free users may only listen in on others.

\n\n

The Share tab is where users are able to toggle their broadcasting status to either on or off. When a user starts broadcasting, other users may start listening in on his/her cast. Any track that is playing in Spotify will be broadcasted as well as player status (pausing, restarting, etc.). The user is able to view what is being broadcasted in the player bar (styled similarly to Spotify's player bar) and who are listening.

Discover

The Discover tab is essentialy a list of all contacts also registered with Shard. If a user is broadcasting, a button will become active, allowing them to start listening to that user (or stop listening). Users are able to favourite contacts by pressing that contact for a short period of time. This will place them on a seperate favourites list for easy access. The player bar on the bottom of the screen shows the track that has been received last, together with the player status. A '+' (plus) sign will appear that allows users to add the current track to one of his or her Spotify playlists. Featured casts allow users to listen to broadcasts of users not in their phone contacts.

Stats

This screen shows general user specific stats such as the average and peak number of listeners; a top 3 of listeners; The total time broadcasted and listened; the users' most listened to broadcast; as well as the overall best listened to broadcasts in the app.

Profile

Details such as a user's name, email address, password, or phone number can be edited on this screen. A profile photo can also be uploaded or edited through the user's album or taken directly with the phone's camera.

$\"Figure$

Figure 2. Overview of the app screens. a) Register and login screen. b) Share tab where the user is able to toggle their broadcasting status. c) Discover tab where the user is able to start listening to friends if they are broadcasting. d) Profile editing screen.

\n","readingTime":"4 min read","fullURL":"https://pingen.dev/projects/shard"},{"slug":"soundtag","title":"Soundtag","featured":false,"creationDate":"2015-04-01","category":"Project","excerpt":"Soundtag lets you tag locations with audio messages or music files. Mark your favourite jogging route with mp3 files, leave a romantic message for your lover at work, or remind your roommate to pick up some beer at the supermarket!","labels":[{"id":"web","name":"Web"},{"id":"music","name":"Music"}],"cover":"soundtag.jpg","html":"

Introduction

Soundtag was created as a fun way to reach out to friends, family, and complete strangers, using soundtags: audio files identified by a specific geolocation. When you are near a location marked with a tag, the app will pick it up and start playing the audio file instantly. Travel, search, discover!

The project comprises of a web portal and an accompanying Android app. Users are able to register on either application, but must have an account to login and start using the service. Details such as name, email, and phone number must be filled in.

After logging in, users are directed to the dashboard's map page. This is where a map of all soundtags created by the user can be viewed. New tags can also be created here, as well as changing the home location (initial map view coordinates).

$\"Figure$

Figure 1. Map view. Users are able to view their soundtags on the map; add new tags; and change their home location.

Creating new soundtags is done through a modal dialog. Users pick a position by dragging the map to the desired location (or search for one using the search bar). Audio files up to 10MB can be uploaded to the application. By adjusting the visibility settings, users are able to mark their soundtag as private (only visible to the user itself), or public (visible to anyone). If the public option is chosen, the tag is visible to any Soundtag user by default. If contacts are added, the tag will be visible to only those contacts. Contacts are imported from the Android app and are updated when the user logs in.

Private soundtag use could include reminder yourself to make a phonecall, or a number of tags along your jogging route. You could use public tags to send messages to your friends and loved ones, or complete strangers. By default public tags with no attached contacts can be viewed in the app, but are not played automatically, unless the user enables this setting. Private, and public tags sent to specific contacts will automatically play by default (but this behaviour can also be changed).

$\"Figure$

Figure 2. New soundtag dialog. Users are able to drag the map to a position (or search for it manually), select an audio file to upload to that location, and set visibility preferences.

To give users easier access to all of their soundtags than the map view, the audio view lists all of the tags together with map links, and deletion option. Tags can be played here as well to better identify them, or downloaded to store a precious memory.

Additionally, on the settings page settings such as name, email, phone number, and privacy settings for new sountag default visibility may be adjusted.

$\"Figure$

Figure 3. Left: The audio view lets users quickly browse through all their created tags. Right: General settings can be edited in the settings view.

\n","readingTime":"3 min read","fullURL":"https://pingen.dev/projects/soundtag"},{"slug":"vie","title":"Vie","featured":false,"creationDate":"2015-03-01","category":"Project","excerpt":"Vie is a project that lets users create a collaborative playlist using Spotify. A party host can set up a playlist, and users are able to add songs to the playlist (without owning a Spotify account themselves) through a web portal, and vote their favourite tracks to the top of the playlist.","labels":[{"id":"web","name":"Web"},{"id":"music","name":"Music"}],"cover":"vie.jpg","html":"

Introduction

When you're hosting a party, oftentimes people have music suggestions, both before and during partying. Vie lets you create a collaborative playlist, using Spotify, that allows other people to add and vote for their favourite tracks. Your guests can have a say in what is being played, though the host is always in control.

This project was done to familiarize myself with the Node.js platform. Vie runs as a Node.js Spotify app (note: the Spotify Apps API has since been discontinued), as well as through a web portal. The host starts by creating a new Party in the Spotify app. A random 5 digit Party ID will be generated for the host to display at his/her party. Party-goers can then enter the Party ID on the web portal to login and start adding tracks.

$\"Figure$

Figure 1. Web landing page. Users may get access to the dashboard through their unique party id.

The Spotify app is meant to function as the party hosts' access panel. Beside creating a new party, a party host is able to login with his/her previously generated party id. An overview of the current playlist, as well as number of votes per track, and tools for deleting, reordering can be found here.

The web portal allows other people to search for tracks using the Spotify Web API without requiring a Spotify account. An overview of the current playlist is shown, as well as options to add tracks to the playlist as well as vote for their favourite tracks. Users may only vote once per track, and tracks are ordered according to number of votes. Of course, the party host is free to override or disable this feature.

Party playlists are automatically removed from the system after a period of nonuse, unless the host opts to store the playlist for future use. Tracks may also be stored to a seperate playlist to store for another time.

$\"Figure$

Figure 2. On the dashboard page users are able to search for music in the entire Spotify library through the web API, and add them to the queue; vote for their favourite tracks; or remove tracks from the list.

\n","readingTime":"3 min read","fullURL":"https://pingen.dev/projects/vie"}]

Introduction

Research

Implementation

Initial ranking

Relevance feedback and reranking

Method

Results

Conclusion

Further reading

References

Introduction

Competitive StarCraft

Research

Bot Overview

Features

Data

Strategy Tree

Strategy Recognition

Strategy Generation

References

Introduction

Research

Robot platform

Hardware

Software

Experiment

Further reading

References

Introduction

Edge detection

Strategy

References

Introduction

Grawe

Graaf

Experiment

References

Introduction

People stream analysis

Crowd behaviour patterns

Data

Method

Preprocessing

Optical Flow

Jacobian and Eigenvalue maps

Feature detection

Results

Conclusion

Further reading

References

Introduction

Overview

Share

Discover

Stats

Profile

Introduction

Introduction