Testing Report : July 11th 2001
Devon Island, Nunavut, Canada

Phase I

Testing started: approx 10 am
Testing finished: 3:30 pm

- Gather data for component test 1.1.1 (robot speed, power and steering radius)
- Collect stereo image pairs to verify calibration.

- Collected power, GPS and steering data for 20 m left, 10 m left (GPS
questionable), 20 m right (GPS questionable), 10 m right, 5 m right, 2.5 m right
turns. Verified that data collected were valid. Probably also collected enough data
for straight arcs, but this has not yet been verified because they were not
commented explicitly in the log.

- GPS converged very reliably in the afternoon.

- Took around 250 stereo pairs for analysis. Initial analysis of these
pairs, which depict flat ground, positive obstacles such as rocks and negative
obstacles, seems to indicate that calibration is reasonable enough to carry out stereo component tests.

- Had many problems with wheel 1 becoming disabled. This stops robot
motion and as long as the wheel stays disabled, motion is impossible. Sometimes the
wheel re-enables itself, other times it stays disabled until a "SH A"
command is given to the Vehicle Controller (NOTE: at first we thought hitting the Galil
reset button was the only solution, but now this can be fixed remotely). Why
this wheel spontaneously disables is unknown. Possible reasons proposed have been
because of cold motors, tight turns, slopes, etc., but none seem to explain the effect.

- Saw a lot of current limiting on several wheels. This can cause
steering to fail when one wheel cannot spin as fast as commanded. Once going over a
rock the steering axle spun around to 14.7 deg when it should've been straight.

- GPS dropped out of convergence during the 10 m left, 5 m left, 2.5 m
left and 20 m right turn tests. Not sure why this occurred, but later in the
afternoon it did not occur.

- Several computers have very inaccurate clocks, especially after they
are power cycled. This has occurred on grex, nunavut and sunsync. This caused problems with
the State Estimator on sunsync.

To Do:
- Figure out the cause of the amp disables and propose a solution.
- Keep an eye on clock settings on all computers before testing, and update them as necessary.
- Perform stereo characterization tests (1.2.1 and 1.2.2).

Phase II

Testing started: 8:00 pm
Testing finished: 10:45 pm

- Collect data to characterize battery discharging behavior, taking
readings of battery with voltmeter and then driving around to run the battery down.
- Collect data for steering latency tests (a subset of test 1.1.3, but without
varying the steering control loop gains).

- Took battery voltage readings manually every 20 minutes for over 2
hours, as the battery voltages dropped from 25.55 V to 23.4 V (near what we consider
too low for operation). Between readings there was a good bit of
driving, and logging of data from the Galil and PMAD, which should allow us to correlate
driving commands to power status at a rate of about 1 Hz.

- Collected data on how quickly robot transitions between the following arcs:
2.5 m left -> 5 m left -> 10 m left -> straight -> 10 m right ->
5 m right -> 2.5 m right -> 10 m right -> 10 m left -> 2.5 m left

- Saw usability problems with Operator Interface -- when the robot is
stopped for some reason (such as an E-Stop or amp disable), the commanded speed in
the Drive Tool Window doesn't go to 0. Therefore, if you try to send another
command, say to straightened out the wheels, the robot drives when you don't expect.

- Wheels 2-4 current limited and it seemed like the robot stopped. not
sure if this actually happened.

- Something strange happened with the E-Stop -- I sent an E-Stop from
the Operator Interface and saw wheel velocities go to zero. However, Jim and Ben reported
that the robot kept moving for several minutes. They hit the E-Stop switch on the robot to stop it. The cause of this problem is unknown, and has not been seen previously.

To Do:
- Gather logged data off sunsync (forgot to do this last night).
- Plot battery discharge behavior.
- Quickly analyze steering latency data to make sure we logged what we wanted.

  ©2001 Carnegie Mellon University - Robotics Institute