| Main Page | Using Pillar Navigation | Media |
The most general class of shapes in Tekkotsu is the blob. Blobs are defined by a rectangular bounding box made in the camera space, which is then projected into local space in some way. The means of projection can vary, which is one of the key features separating the three types of blob shapes: groundplane blobs, which are the standard form; posters, which are vertical blobs suspended some distance above the ground; and pillars, which are vertical blobs with bases in the ground plane. This project aims to improve pillar functionality in Tekkotsu and use these improvements to demonstrate the ability to navigate around a plane occupied by two pillars.
As mentioned above, pillars are one of three types of blobs in Tekkotsu, and the type which is least well-supported. The key to understanding what a pillar is lies in knowing how they are projected into local space from the camera space. While groundplane blobs are projected by projecting each of the bounding box's four corners and using the projections to form corners of a new quadrilateral, with pillars the idea is that the upper corners should instead be situated above the lower corners. Thus, while it is easy to project the bottom corners if they are visible, doing anything else can be problematic.
Assuming that the bottom corners are properly found and do not run off the bottom of the camera's field of view, there is still not a particularly simple way of finding the height of the pillar. Previously, there was no option at all for what to do when there was no height assumption -- the pillar would simply be considered to be height 0 in that case. However, it is in fact possible to estimate the height if the top of the pillar can be found. This is done by projecting the top points of the pillar to the ground plane, then using similar triangles. The idea here is that there should be two right, similar triangles which share the projection point of the top of the pillar as a vertex: one has the distance from the point directly below the camera to the top projection as one leg and the height of the camera as the other, while the other has the distance from the bottom projection to the top projection as one leg and the height of the pillar as the other. Hence the height can be found by observing that the height is to the camera's height as the distance from the top projection to the bottom projection is to the distance from the top projection to the point directly below the camera in the ground plane.
These estimates usually fall within a centimeter or two of the actual height, as tested on objects 10-25 centimeters tall from various distances.
Aside from the ability to estimate heights, greater support has been introduced for projecting pillars that have a height assumed in advance. Provided that the top of the pillar is on-screen, it can be projected to a plane elevated to the assumed height of the pillar. From this, the bottom of the pillar can be found simply by subtracting the height.
Finally, a minor modification was made to Tekkotsu's particle filter to take advantage of the new support for finding heights: now it will distinguish between two pillars based not only on their centroids, as had been the sole means of distinguishing blobs of all sorts, but now will check the heights as well. This allows for the particle filter to correctly discern its location given two pillars of the same color, which would be ambiguous if only the centroids are considered.
While the modifications to the way Tekkotsu handles pillars are nice, they do not innately allow for pillar navigation. To do this, I have developed three state machines, the first two acting as intermediate steps for the third. Note that all of these were developed for the specific case of two distinctly colored pillars, one green and one pink, and so make some assumptions that negate the usefulness of the modifications listed above. For example, since it is assumed that there will only be one height for every pillar of a given color, after a height is found for a pillar, that height is assumed for all subsequent pillars of the same color, which renders the changes to the particle filter useless.
The first state machine I developed can be used when the robot's position is fixed aside from the camera. The idea here is to find all of the pillars in the area visible by moving only the robot's head and to determine a base and a height for each one. Since this is designed for the two distinctly colored pillars example, it will look for pillars in the world space and use their heights if any are found.
This state machine operates by first scanning for groundplane blobs -- unlike pillars, there is no check to see if a groundplane blob runs off the bottom of the screen, making it useful to use them when searching for general blobs. Each groundplane blob is then examined in turn, with the camera panning up and down as necessary to attempt to identify its base and height. The results are then stored in the local space, which is useful for localization with the particle filter.
Next I looked into the problem of how to set up the world map initially for the two pillars case, starting with the robot in an arbitrary position in a plane that is assumed to contain exactly one pillar which is green and one which is pink. Generally this can be solved merely by rotating around, but this fails to consider the case where one pillar is blocking the robot's view of the other one. If the robot determines this is the case, it will relocate itself to a position alongside the one visible pillar and look beyond it, hopefully finding the second pillar in the process. Unsurprisingly, this state machine makes use of the previous one when scanning for pillars at each new position, after which it imports the results in the local space into the world space.
Finally, there is a state machine designed to do a simple relocation, while checking its position periodically by determining its location relative to the known pillar locations. This naturally uses both of the previous state machines as nodes, starting with a call to the second state machine and periodically calling the first. This makes use of the fact that the robot has a rough idea of where it is at each update, and so does not need to scan blindly. Rather, it faces the direction it assumes is towards the blobs, then scans for them. If only one blob is seen even though both are in the same general direction, it will assume one is occluding the other and determine its position based on this, rather than by using the particle filter. If it believes, based on its assumed position, that the pillars are flanking it, it will skip one localization and advance again, hopefully moving forward far enough that the pillars can be seen at the same time. Otherwise, both pillars are scanned and the particle filter is used to determine location. The robot repeatedly relocates and relocalizes itself until within five centimeters of its target, which is always located at the point half a meter in front of the robot's initial position. Since this is not really about path planning, it is assumed that the pillars are not in any way impeding the robot's progress.
A question I asked myself occasionally. What is the point of having separate functionality for navigating with pillars, when blobs are already supported? While groundplane blobs are fine for some tasks, when the robot is moving, any non-planar shape will cause issues if assumed to be planar. As a simple example, suppose you have a rectangular block that is an inch thick, and when viewed from three inches away it projects to a shape a foot long. When viewed from the opposite side at the same distance, it will produce another foot long blob. Thus while the robot has only moved seven inches, if the projections are used as navigational cues, it will appear that the robot moved a distance of eighteen inches instead, since it would have to have covered the entire length of the object. Pillars in fact have the opposite problem -- since the projection of a pillar is two-dimensional, it treats pillars as though they have no thickness. For a tall, thin object, this produces significantly better results. The point here is that no single representation will account for every case, and so both pillars and groundplane blobs have their uses.