ith a training set of just a dozen positives from a single car I have let the experiment run. The purpose of this experiment is to test the alarm (collision) mechanism for short-range D alone.

Dashboard and tracking enriched somewhat, footage on Motorola Droid (captured by someone else). I’ve not gotten around to implementing better tracking yet.

ascade classification is easy to work with in OpenCV, but it is not so well documented. This series of short videos explains how this is done on GNU/Linux-based systems (although it may be useful and applicable to other platforms too). The videos were not scripted or planned, so please excuse the occasional stuttering and mistakes.

Keywords: OpenCV android linux gnu ubuntu cmake eclipse computervision research haar tracking machinelearning

AM going to start an Android project quite soon, as my latest posts probably helped show. The drawback is that it will be less research-oriented and more implementation-oriented. On the other hand, Android is becoming de facto OS in the mobile market and it increasingly seems like Dalvik development is a valuable skill. My three siblings all use Eclipse and my fiancée studied Java back in the days as well, so it only makes sense for me to come back to Java. Currently we explore what the project will involve, with questions arising such as:

• What features are simpler to implement for baseline functionality, e.g. collision detection?
• What framework, e.g. opencv, is available for rapid development?
• Possible technical collaborations of relevance?
• What is the innovation worth exploring/adding?
• Is stereovision (deriving 3-D) an option or just 2-D?
• What products are already out there and how competitive are they?

s a bit of a dinosaur in technology (I still use a Palm PDA and single- or dual-core AMD), backward compatibility and long-term support are important to me. I am not a fan of PHP even though many programs that I like (the latest being Roundcube) use it almost exclusively.

Many problems seem to occur for those who use old versions of Gallery with the latest PHP, which has become notorious for its backward compatibility deficiencies. One bit of software that I use which is not compatible with PHP 5.3 is Gallery 1.x. It’s a version that I hacked a bit to suit my purposes, so upgrading would flush all my customisations away. Whether a sandboxed compatibility mode is available (such that, e.g., PHP 5.2 is run for specified paths) I do not know yet, but based on what people are saying suppressing the warnings and errors should be possible. It’s not a real solution but a cosmetic hack. If your Web host undergoes a PHP upgrade to 5.3 it can lead to lots of issues associated with out-of-date software. “A short time ago,” wrote my host (with which I host about 10 domains), “we emailed you to let you know that we were upgrading all our servers to the latest version of PHP. This is now complete. We therefore recommend you have a quick check of your site and ensure everything is working as it should.”

The bottom line is, from my personal point of view, is that PHP yet again proves that backward compatibility is too much for it to handle and, as such, one oughtn’t rely on long-term usage of programs written in PHP. Other authors pointed this out before. It’s quite the blunder. In Web-based environments in particular, a case of “lose compatibility or get cracked” may become more common if we become dependent on PHP.

ar navigation using computer vision algorithms/programs (as opposed to GPS/maps) is scarcely explored in the form of mobile applications. With many built-in cameras and increasing processing power/RAM it would be desirable to exploit — to the extent possible — whatever general-purpose devices have to offer while idle; single-purpose appliances like TomTom make less business sense nowadays and development frameworks for mobile platforms have become versatile enough to empower third-party developers. Based on conversations with colleagues, OpenCV and its many plugins should be somehow available for Android as well, albeit it may require some hacking and adaptation to the hardware at hand (high-end ARM for the most part).

If the goal is to make vehicles with cameras mounted onto them interpret a scene like humans do, then analysis of video sequences on mobile hardware (efficient applications) ought to be explored, with special emphasis on performance. C++ has little memory footprint and high efficiency. Contemporarily, resolution at a high capture rate is satisfactory enough for the task, but it is unclear whether a good algorithm that segments and tracks a scenes can keep up. A GPU-like processing power is available on some phones, but not all (drivers for non-x86 architectures are poor or scarce, too). MobileEye offers peripheral and assistive hardware for this reason, recognising the known caveats.Vuforia does augmented reality for mobile platforms and a company called ThirdSight also makes mobile applications with computer vision methodologies. Not so long ago (April 2010) it was reported that “development of new automobile safety features and military applications [...] could save lives.” The hardware is not specified in the report. To quote, “Snyder and his co-authors have written a program that uses algorithms to sort visual data and make decisions related to finding the lanes of a road, detecting how those lanes change as a car is moving, and controlling the car to stay in the correct lane.”

While purely automatic driving is currently verboten, computer-aided driving is legal and forms a growing trend. It need not involve any mechanics either, as it’s most about message-passing to a human (HCI).

ccasionally, in numerical programming, one may wish to plot or instantiate a grid of a circular (or spiral) nature. Here are some code samples for those trying to achieve it. The following sets some values of interest:

lines=10
degrees=180

Now, let us generate some linear, equally-spaced points:

t_map = linspace(0,lines*pi*2,lines*degrees*2);

What we have here is the 2 for 360 degrees, which may depend on what one tries to achieve. For the more complex case shown later, this will be essential. Now, let’s do the sine/cosine magic:

x_map = t_map.*cos(t_map);
y_map = t_map.*sin(t_map);

This can be plotted with plot(x_map, y_map), but let’s do something more interesting by assigning colour to the sample points and then plotting them as dense dots. The following would work:

flat=zeros(1000,1000);
  for ll=(size(x_map,2)/2):-1:1
    flat(floor(x_map(ll*2))'+500,floor(y_map(ll*2))'+500)=1
  end
imshow(flat)

The values here are rather arbitrary and can be used for demonstrative purposes. The problem itself seems to be commonly recurring, thus the need for a blog post. Different colours can be assigned to sample points, which achieves something like the following: