| I am working on getting my Roomba robotic vacuum to communicate via its serial port. This project is in the early stages, but I hope to be able to apply previous work (see below) to a much cheaper robot platform. | ![]() |
For my M.S. research I analized how to learn multi-resolution distribution of contours. The idea is that it makes sense to make classification decisions based on the overall shape of an object and ignore the details. However, in other situations, those details are important. The two main challenges were: 1) choosing a representation for the shapes that allows comparison and manipulation without introducing dependencies on the particular representation, and 2) finding an appropriate trade-off between global and local information.
![]() |
| A multi-resolution decomposition of the outline of a maple leaf. Each outline shows the addition of one level of detail. When does the blob become a maple leaf? |
I am continuing to refine and document some of the Matlab code for this project and plan to make it available on the web.
Size functions attempt to describe the characteristic features of a shape in such a way that if only part of the shape is visible, the shape can still be recognized. An appropriately chosen size function can be rotation invariant and normalized to remove scaling.
![]() | ![]() |
| A size function plot (right) can be computed for a contour. The plot describes the curvature and connectedness of the shape. More information about size functions is available on the website of the group that developed them. | |
I initially investigated size functions for my undergraduate mathematics thesis. (I am grateful to Jeremy Martin for patiently advising it.) In subsequent work, I developed Matlab software to generate and compare size functions from character images in a few different ways with the intention of applying them to Optical Character Recognition (OCR) problems. My experimentation validates that size functions can be an effective way to compare outlines of shapes that can be described as a simple closed contour. However, they are not always as useful when comparing more complex figures.
The goal of this project is to enable a human operator to have a high level of manual control of a robot, while not having to worry about endangering the robot. The project was a part of a course on robotics taught by Stergios Roumeliotis.
![]() |
| The path taken by the robot as it navigates the 5th floor of the Computer Science building. There are several people standing around, causing additional noise. Note that the robot avoids all obstacles, then returns to its target course, which is near horizontal in this view. |
The project used the Aria robot API (C++) to control an ActiveMedia Pioneer robot equipped with a SICK laser range finder. The robot's position is tracked using its wheel encoders, which is a notoriously inaccurate method. However, since obstacle avoidance is meant as an assistng technology, this level of error is acceptable.
Every two years teams of undergraduate students from around the US and Canada design and build cars powered exclusively by the sun and race them across the country. I was part of the team that built the University of Minnesota's Borealis 3 car, and was a race strategest for the 2005 North American Solar challenge. The Minnesota team was runner up by a narrow margin of 15 minutes out of a 54 hour, 2500 mile race. Minnesota won first place at the 2005 Formula Sun Grand Prix.
I was one of two members of the race strategy team. The strategists are responsible for controlling the car's energy output via its speed. Of course, the overall race goal is to be the first to cross the finish line. However, in order to do this, a successful team must carefully manage how much energy remains in the car's battery. When the car crosses the finish line, the battery will ideally be empty; if not, the car could have driven faster and crossed the line sooner. But, if the battery is drained too quickly the car must slow down and is at risk to be caught by competitors. Complicating the situation is the fact that the power required to drive at any given speed is proportional to the cube of that speed. (This is why you burn more gas driving 80 vs. 70 than 70 vs. 60, and why speeds were regulated to 55MPH during the oil crisis of the 1970's.)
![]() |
![]() | |
| Power required to drive vs. Road Speed | Battery energy (predicted and observed) vs. Time for a two day stage of the race |
The strategist would like to set a target speed that is constant for as much of the race as possible. In an attempt to do this, we built mathematical models to aid in estimating how much power would be drawn from the battery. Power comes from the sun, so the models must account for the car's position on the Earth, the time of day, and the direction of travel. The models must be able to be adjusted easily "on the fly," since the biggest variable in a race day is the weather. Our models performed well, and we were able to stay close to our target battery charge level.
Borealis 3 has a digital control system based on Freescale (formerly Motorola) MC68HC908 microprocessors. The various circuits communicate with an automotive grade bus (BDLC). Since this was Minnesota's first car to have all of its control software written in C, I spent much time writing and debugging the bus subsystem. I also wrote the software responsible for controlling the car's motor. Data from the bus was forwarded via a radio link to the chase van where the strategists (who also happened to be responsible for creating most of the control logic) could monitor the car. Since all of the telemetry was stored in a MySQL database, we could look back at the data to diagnose problems if necessary.
mail@tomwhipple.com
612-220-1465