Devon
Island, Nunavut, Canada
Phase I
Testing started: approx 10 am
Testing finished: 3:30 pm
Agenda:
- Gather data for component test 1.1.1 (robot speed, power and
steering radius)
- Collect stereo image pairs to verify calibration.
Progress:
- 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.
Problems:
- 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
Agenda:
- 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).
Progress:
- 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
Problems:
- 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.