Friday night in Montreal, with the streets being almost blocked by a snowstorm that left us half a meter of snow between our door and the outside world. It is also a night in which my next-door neighbours have decided to test the full extent of their speaker’s bass capabilities — currently playing a remix of Lana Del Rey’s Blue Jeans. It’s impressive to hear that they are accompanying the song during its high notes; perhaps it’s time to throw that neighbourhood karaoke party after all.
What’s also impressive is that this note has diverged so early on, from its first paragraph. This note is actually about a literature review of a set of pattern recognition and robotics papers, whose existence I think is important to know. I wrote this review as a partial requirement for my upcoming Ph.D. comprehensive exam at McGill. The purpose of the literature review is to summarize ~20 papers related to your research area, and the committee is free to ask whatever question they wish around these papers and their references, trying to see exactly what are the boundaries of the student’s knowledge and how this knowledge has been acquired: by memorization or by actual understanding. If the student is unclear about a method or an algorithm, this committee, which consists of some of the most experienced professors in the department, will most likely detect it and dig deep enough with questions to see exactly what the student does not understand and why.
My review document covers some methods in these broad topics:
- Bayesian filtering and estimation
- Sampling-based path planning
- Classification and ensemble methods
- Active vision
The summary is quite dense, and admittedly one could spend an entire document focusing on one of these areas. I though it was going to be more fun though to write a compact document. I should clarify that this document has not been reviewed yet by the committee, so I haven’t received much feedback on it, and I don’t know exactly how many errors it contains. Notwithstanding that, I thought it is useful enough to share.
If you are searching for a new activity this semester, and you think you want to give horseback riding a chance, then you can go to the McGill Athletics website and sign up for 1 of 12 available slots. The lessons take place at a school called Equitation Elysee, in a farm in St. Lazare, one-hour drive away from downtown Montreal.
Commuting there by public transportation is next to impossible, but if you don’t have a car, the instructor will put you in contact with other students who do, so you can share the ride. The students range from 5-year olds to 70-year olds, and a previous background is not assumed. The instructor, Jo Sweet, is very experienced, she will tell you when you’re doing things wrong and will help you individually to improve your technique. A typical lesson starts with the student grooming the horse in the stables before the ride, then guiding the horse to the arena for the exercises. I should mention that the purpose of the lessons is to control the gait and speed of the horse, and eventually perform jumps; not to simply go riding along trails. The arena is cool though, and there is classical music playing while you’re training. The school runs all year round, and you can contact Jo even if you’re not a McGill student.
One of the courses I was taking during my third year of undergraduate studies was a full-year Abstract Algebra course, covering among others ring theory and Galois theory in great detail. The course was a requirement for my program, and it was one of the few courses that I was not sure at all I’d enjoy. It turned out that many of my friends in Math enjoyed it, but I didn’t. I felt no, or very few connections with Computer Science (later I discovered through friends that if you study advanced complexity theory and theoretical Computer Science it will be very useful), and as a result I started feeling unmotivated.
At some point during the same year I found a book called “Mathematics and Technology” by Christiane Rousseau and Yvan Saint-Aubin. This book was different, extremely refreshing and motivating. Each chapter is a technological problem that has been solved via applied mathematics. For instance, it presents the math behind: the trilateration of the GPS, the motion of a robotic arm in 3D, error correcting codes, public-key cryptography, Google’s PageRank algorithm, why MP3‘s are sampled at 44.1Khz, the JPEG compression standard, the DNA computer (super-cool chapter!), and many other applications. The book is simply a collection of really interesting problems, accompanied by the mathematical background and principles that allow the reader to understand the basic solutions to those problems. It’s not a perfect or comprehensive book by any means, but it is a beautiful one, in the sense that every chapter is a nicely-told story and the provided theory is strongly tied to each application. I think the mathematical maturity it requires is at most that of a 3rd year undergraduate student in math, though I’m sure you could understand most of it with a basic Calculus and Linear Algebra background.
Richard Hamming’s “You and your research” is an essay that is often recommended reading for graduate students, as a means of advice from an accomplished scientist. I agree with most of the points he raised: work on the important problems in your field, get the courage to try to solve them, be prepared, be patient and positive etc. There is one point that he made though, which has really bothered me from the day I first read the transcription of his speech:
I had incipient ulcers most of the years that I was at Bell Labs. I have since gone off to the Naval Postgraduate School and laid back somewhat, and now my health is much better. But if you want to be a great scientist you’re going to have to put up with stress. You can lead a nice life; you can be a nice guy or you can be a great scientist.
This really doesn’t make much sense to me. Why does willingness to compromise your health make you a more dedicated scientist? Is a sick or dead scientist better than a healthy one? Is constant stress and fear a prerequisite for being productive and creative? I don’t think they are.
I think I prefer Emerson’s “The American Scholar“.
I think this is the first TED talk I ever watched, and it still remains one of my favourites:
This post is a series of instructions on how to use your own version of the opencv library with ROS. If you’ve had trouble doing this then you’re probably familiar with these instructions — while they are good in general, they are misleading because they assume that you are using the latest version of ROS, which I’d guess is not true for most people. Anyway, here is the story in more detail if you have no idea what these terms refer to:
opencv is an open source computer vision library. It provides implementations of the most popular computer vision algorithms that have appeared in the vision research literature. Needless to say that it evolves very quickly. The latest version is 2.2 and provides support for a large number of feature detectors and descriptors, aside from the classical SIFT and SURF. In case you didn’t know, it also provides face detection and recognition classifiers, image segmentation, object recognition, tracking, and many other goodies.
ROS stands for Robot Operating System. I guess it’s fair to say that its aim is to become for robots what Linux became for computers. ROS is the software platform running on the PR2. It provides support for many sensors and offers abstraction layers that allow roboticists to share code more easily. Code in ROS is organized into entities that are called “nodes,” which communicate with each other by exchanging standardized messages. For instance, ROS offers a node for firewire cameras, which publishes image messages. An image viewing program listens for image messages and when it gets a message it displays it on the screen. The point here is that the communication between the publisher and the listener relies on a standard image message interface, which means that I can write the former and you can write the latter, and we won’t have problems sharing our code. ROS is designed to be distributed, its nodes may run on different machines in the same network. This is all good news, because for the first time (?) the robotics community has a software platform that is very well designed, takes care of most details, and is not going to die soon because of low contribution.
But anyway, I have digressed. This is not a fanboy post about ROS and opencv. My problem was that the latest stable distribution of ROS, called “cturtle,” comes with opencv 2.1, while I wanted 2.2. Since many nodes in ROS depend on opencv, changing its version means that you have to recompile a big part of the system. This page helped a lot, but it didn’t work for me, because it assumed that I was running the latest (unstable?) version of ROS. As a result, compilation was unsuccessful. Here’s what worked at the end:
- Create a file called something like cturtle_overlay.rosconfig and paste the following in it:
- svn: uri: https://code.ros.org/svn/ros-pkg/stacks/vision_opencv/tags/cturtle local-name: vision_opencv - svn: uri: https://code.ros.org/svn/ros-pkg/stacks/image_transport_plugins/tags/cturtle local-name: image_transport_plugins - svn: uri: https://code.ros.org/svn/ros-pkg/stacks/image_pipeline/tags/cturtle local-name: image_pipeline - svn: uri: https://code.ros.org/svn/wg-ros-pkg/stacks/web_interface/tags/cturtle local-name: web_interface
- Create a directory named something like cturtle_overlay on your local workspace.
- Run “rosinstall ~/some-path/cturtle_overlay /opt/ros/cturtle ~/some-path/cturtle_overlay.rosconfig”
- Edit “~/some-path/cturtle_overlay/vision_opencv/opencv2/Makefile” in order to specify the version of opencv source you’d like to fetch. In my case it was:
SVN_URL = https://code.ros.org/svn/opencv/branches/2.2/opencv SVN_REVISION = -r4351
- Append “source ~/some-path/cturtle_overlay/setup.sh” in your bashrc file, and make sure that the paths in setup.sh are correct.
- Run “rosmake -a”
Hopefully, everything will go smoothly after this.