SURF-IT Progress Report

Autonomous Systems Lab

Summer 2007

Scott Triglia

Abstract: This document covers the tasks I accomplishedduring Summer 2007 in the Autonomous Systems Lab. This includes corrections to instructions about autonomous Overbot operation and CVS setup as well as work on the Overbot itself.

Table of Contents

1Correction to Overbot Operation Instructions3

2Adding New Users to the CVS Repository3

3UNIX/QNX4

3.1Adding New Users to the Overtux Server 4

3.2Changing File Permissions 4

3.3Forced Copying of Files 5

4Object Inflation5

5Error Tracking6

1Correction to Overbot Operation Instructions

In previous reports, the steps for operating the Overbot autonomously were slightly incorrect. The proper steps are as follows (terminal commands are preceded by ‘#’):

Open the QNX terminal

#ssh vehicle@gcrear0

Type vehicle as the password when prompted

#usercontrol

In usercontrol select the desired waypoint file

In usercontrol set the vehicle to active

Switch the vehicle into AUTO using the panel to the left of the steering-wheel

Use the E-stop remote and select RESET/ON

Use the E-stop remote and select PAUSE

In usercontrol select “reset” and then “exit”

Stand clear of the vehicle and hit RUN on the E-stop remote.

Notice that the Overbot must first be set to AUTO before the E-stop remote is turned on.

2Adding New Users to the CVS Repository

Adding new users to the CVS repository is done as follows. All terminal commands are preceded by the ‘#’ character.

1) Add the new username to /cvs/newcvs/CVSROOT/writers by typing:
# echo newuser > writers

Check to see that formatting looks like:

User 1

User 2


2) Backup old passwd file and add new password to /cvs/newcvs/CVSROOT/passwd:
# cp passwd passwd.DATE (replace DATE with MMDDYY)
#htpasswd -n newuser > passwd (enter pass when prompted)
Open passwd and append ":cvs" to the new entry (format of each line is user:passwd:cvs)
3) Add newuser to the group cvsusers
Open the /etc/group file
Add ", newuser" to the "cvsusers" line in that file
Note: If attempting to check out a copy of the repository on overtux, type the following at the terminal before using "cvs checkout" to make sure you are getting the current Overbot code rather than the old versions.
#export CVSROOT=/cvs/newcvs

3Unix/QNX

There are various workarounds for existing problems using Baja, the Overbot laptop, as well as the Overtux server(overtux.cse.uscsc.edu). The solutions and/or workarounds that were used this summer are covered here.

3.1.Adding New Users to the Overtux Server

SSH or log in directly to the Overtux server, then complete the following steps, substituting the actual user name and password for username and password.

#useradd username

(see for extra options)

Enter password when prompted

This will set up a new user on Overtux, with name username and password password. Their home directory will default to /home/username.

3.2.Changing File Permissions

Occasionally when using either Baja or Overtux, the need arises to change the permissions on a file. This is accomplished through the chmod command. The use is as follows:

#chmod xxx filename

The filename can be either a directory or a file, and the three digit number determines the permissions you are setting. Each digit corresponds to permissions (read/write/execute) for one group. The three groups are the user who created the file, the group associated with the file, and all users respectively.

To determine what settings the value of the digit corresponds to, calculate the sum of the attributes you want (r/w/x) with r = 4, w = 2, x = 1. Thus setting rwx would be 7, rx would be 5 and w would be 2. Repeat this for each of the three groups.

To view the file permissions of a file, type ls –l in the directory containing that file.

3.3.Forced Copying of Files

Occasionally, Baja will have a problem copying files over to gcrear0, saying that the resource is currently in use. Check that you don’t have any programs actually using that file first, then simply rm the file you want to replace, and copy as normal. The actual cause of this error is unclear, but perhaps due to some background process running on gcrear0.

4Object Inflation

Object Inflation is an alteration made to the Overbot’s collision detection which saves processing by reducing the time necessary to test for collision.

The code can be found in the inflate function in mapudpate.c, which is inside gc/src/qnx/nav/map in the code repository. Additionally, some changes were made to mapcell.h (in the same directory). The pre-integration code is in the gc/src/qnx/Scott directory.

Object Inflation saves processing time by shrinking the Overbot’s width. The Overbot is shrunk to a single pixel in the map, while all objects in the map are inflated by the width of the Overbot. This means that if the Overbot’s single pixel ever intersects either an inflated or obstacle cell, the actual robot will be colliding with an obstacle. Notice that, in the actual code, the circle of inflated cells around each obstacle is approximated by a box and cross shapes. This allows the best coverage, while still keeping the actual inflation as quick as possible.

The pixels surrounding obstacles are inflated at the time the obstacle is inserted in the map. This inflation is done in quadrants, so if a particular set of quadrants have obstacles inside them, they will not be inflated (since this inflation would have happened previously). The actual labeling of the cells as inflated is done by setting each cell type as inflated, which is then colored blue in the final map image.

As of the end of the summer, inflation worked intermittently during test runs. Often, objects would inflate properly. However, at times instead of displaying as blue cells, the area around an obstacle would display the path behind it, as if it had never been scanned by the LIDAR. The current best guess is that this behavior is due to the fact that the map will “forget” data after a set amount of time, and thus preset obstacles need to be refreshed occasionally so the surrounding inflated cells are also refreshed.

5Error Tracking

Error Tracking determines the difference between the expected and actual heading and location of the Overbot. Once these values are found, they are used to correct the inherent error, and keep the Overbot centered on the expected path originally computed.

The method of error tracking is extremely simplistic for now. Actual testing, and more time to program the alternative method, will be needed before deciding if a different method would be superior. Currently, the heading difference is computed as expected, and the cross-track error is computed by finding the closest point on the expected path to the actual robot position, then finding the distance between these two points.

This cross-track method is simple to compute, but may not be the best indication of where the Overbot is most likely to be along the expected path. Future methods could include assuming that a line drawn from the Overbot to its expected position will be perpendicular to the expected path, and compute the expected position from there.

1