<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker</title><link>https://sourceforge.net/p/jaer/wiki/filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker/</link><description>Recent changes to filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker</description><atom:link href="https://sourceforge.net/p/jaer/wiki/filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker/feed" rel="self"/><language>en</language><lastBuildDate>Tue, 25 Jun 2013 07:55:53 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/jaer/wiki/filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker/feed" rel="self" type="application/rss+xml"/><item><title>filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker modified by Luca Longinotti</title><link>https://sourceforge.net/p/jaer/wiki/filt.net.sf.jaer.eventprocessing.tracking.RectangularClusterTracker/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;A very general purpose tracker of small connected objects, preferably circular or rectangular in shape.&lt;/p&gt;
&lt;p&gt;The basic cluster tracker tracks multiple moving objects. It does this by using a model of an object as a spatially-connected rectangular source of events. As the objects move they generate events. These events are used to move the clusters. The key advantages of the cluster tracker are&lt;br /&gt;
 1. There is no correspondence problem because there are no frames, so the events between rendered views still push along the clusters.&lt;br /&gt;
 1. Only pixels that generate events need to be processed and the cost of this processing is dominated by the search for the nearest existing cluster, which is typically a cheap operation because there are few clusters.&lt;/p&gt;
&lt;p&gt;The cluster has a size that is fixed but can be a function of location in the image. &lt;/p&gt;
&lt;p&gt;In some scenarios such as looking down from a highway overpass, the class of objects is rather small, consisting of cars, trucks and motorcycles, and these can all be clumped into a single size. This size in the image plane is a function of height in the image because the vehicles near the horizon are small and the ones passing under the bridge are maximum size. Additionally, the vehicles near the horizon are all about the same size because they are viewed head-on. &lt;/p&gt;
&lt;p&gt;In other scenarios, all the objects are nearly the same size. Such is the case of looking at particles in a hydrodynamic tank experiment or falling raindrops. In other scenarios, objects fall into a distinct and small set of classes, e.g. cars and pedestrians, but we have not developed a cluster tracker that can distinguish these classes.&lt;/p&gt;
&lt;p&gt;The steps for the cluster tracker are outlined as follows. For each packet of events:&lt;br /&gt;
 1. For each event, find the nearest existing cluster. &lt;br /&gt;
 1. If the event is within the cluster radius of the center of the cluster, add the event to the cluster by pushing the cluster a bit towards the even and  updating the last event time of the cluster.&lt;br /&gt;
 1. If the event is not close to any cluster, seed a new cluster if there are spare unused clusters to allocate. A cluster is not marked as “visible” until it receives a certain number of events.&lt;br /&gt;
 1. Iterate over all clusters, pruning out those clusters that have not received sufficient support. A cluster is pruned if it has not received an event for a “support” time.&lt;br /&gt;
 1. Iterate over all clusters to merge clusters that belong to the same object. This merging operation is necessary because new clusters can be formed when an object increases in size or changes aspect ratio. This iteration continues until there are no more clusters to merge and proceeds as follows:&lt;/p&gt;
&lt;p&gt;The tracker has been used as part of Goalie and several other robotic implementations that achieve a effective frame rate of &amp;gt;1k FPS and a reaction latency of ~3ms with a 4% processor load, using standard USB interfaces.&lt;/p&gt;
&lt;p&gt;Has a very large number of configuration options. &lt;/p&gt;
&lt;p&gt;TODO configuration&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Luca Longinotti</dc:creator><pubDate>Tue, 25 Jun 2013 07:55:53 -0000</pubDate><guid>https://sourceforge.nete9ef4664d3029f5bee36d32295c155a3cdb70dc0</guid></item></channel></rss>