On July 25th 2007, the
Autonomous System group undertook a full day cruise to do more
sea trials and validate the work done so far on T-REX, the onboard
deliberative control system on MBARI's CTD
AUV platform. In addition to its main vehicle computer
(MVC), the AUV carried an additional computer (a WinSystems
300 Mhz EPIC GPX-500 running Fedora 6) that ran T-REX. The system is based on
integrating automated planning techniques with on-board plan execution
in a closed loop. This is expected to enable the vehicle to operate
more robustly and more opportunistically with respect to science
objectives. The role of planning in this field trial was to reactively
generate commands to the Vehicle Control Sub-system based on feedback
from the vehicle and to proactively generate plans based on science and
operator objectives. The agent dispatches commands to the vehicle and
synchronizes updates from the vehicle with the expected state of the
plan.
For this mission, objectives were (1) to validate the
changes made to
T-REX based on our 1st trial experience
and (2) to test new functionalities such as : 
- to have longer run than the 1st trial
- to be able to follow multiple links in the path network on the figure on the right.
- to have high-level science and operator goals as input to T-REX
The data below summarizes numerous runs on the 25th. The detailed test plan was the basis for these runs which were carefully thought out and coordinated with the DMO AUV team to tease out any technical issues with the system to date.
Test location :
The test location was in the north Monterey Bay. The maps below show
AUV locations during these tests.
Overview
of the test area
Medium
view
Close-up
to the mission location
The following sections show some of the initial results obtained.
T-REX updates validation :
This validation was done by executing missions from the previous trial allowing us to check if the issues that we encountered in our first cruise were correctly handled by updates to thesoftware. We were able to execute correctly all the missions from the previous trial and it appears that all the issues discovered are now corrected.
Here are some of the missions we were able to run :
A simple mission :
The goal of this mission was to go to the center node (northing=4081.4 km, easting=597.83 km) without any other constraint. The role of T-REX was to look at the current AUV position and decide accordingly what is the best sequence of action to undertake. The mission had the expected behavior as shown on the following results.Plan execution
| date (seconds) | Command | Max. duration |
| 2 | setpoint | 5 |
| 7 | descend | 64 |
| 54 | waypoint | 119 |
| 130 | exit |
Mission path
T-REX
CPU usage
In the figure to the right on CPU performance one can see the effect of synchronisation, indicating the time taken by T-REX to ensure that a newly generated plan is still consistent with its decisions. From a performance perspective, the median value of the CPU usage is 6.8% when on a previous mission it was 14.8% demonstrating the scalability of T-REX to more complex missions.
Check-in window management
In this mission the AUV had to go to the north node (northing=4081.6 km, easting=597.83 km) at a depth of 10 meters. It was also required to pop-up at the surface every 100 seconds for a minimum duration of 100 seconds long to allow us to locate the AUV when at the surface.This mission was also one of our firsts "long runs".
The check-in window is a requirement for this water-column survey AUV enabling it to localize itself using GPS. When in the water the localization method is incremental. As a consequence the AUV accumulates uncertainty in its position as it progresses on its transect. The current operations policy is to surface approximately every 45 minutes for a GPS fix specified a priori, in a manually planned script which can be prone to operator error. T-REX deals autonomously with this localization requirement at plan generation time. We have also added the constraint that this window has a minimum duration giving us adequate time to communicate with the vehicle.
Plan execution
| date (seconds) | Command | Max. duration |
| 7 | setpoint | 5 |
| 12 | descend | 71 |
| 60 | waypoint | 38 |
| 101 | ascend | 71 |
| 175 | getgps | 598 |
| 213 | setpoint | 63 |
| 280 | setpoint | 5 |
| 285 | descend | 71 |
| 331 | waypoint | 46 |
| 380 | ascend | 71 |
| 454 | getgps | 598 |
| 492 | setpoint | 63 |
| 559 | setpoint | 5 |
| 564 | descend | 71 |
| 621 | waypoint | 35 |
| 659 | ascend | 71 |
| 733 | getgps | 598 |
| 765 | setpoint | 69 |
| 845 | exit |
Mission path
T-REX CPU usage
The path executed may look erroneous initially given this non-standard "U" pattern when projected to the surface, when it needed to go straight ? In reality the execution is correct but with a long check-in windows (100 seconds), the AUV was pushed around by surface currents. Despite these surface conditions, T-REX commanded the vehicle with the correct heading (blue arrows) each time the local waypoint was executed to head to the north node.
Long runs with T-REX
Simple path with check-in windows
The first long transect was a mission where we specified that the AUV had to go to the south node (northing=4081.2 km, easting=597.835 km) at a depth of 10 meters. An additional constraint was that the AUV had to check-in every 100 seconds with at least 40 seconds on the surface for a GPS fix. The plan description shows that the mission had a duration of almost 1000 seconds (16 mins 38) and it behaved as expected inserting the surface events with GPS-fixes regularly.
Plan execution
| date (seconds) | Command | Max. duration |
| 7 | setpoint | 5 |
| 12 | descend | 71 |
| 65 | waypoint | 33 |
| 101 | ascend | 71 |
| 149 | getgps | 598 |
| 203 | setpoint | 5 |
| 208 | descend | 71 |
| 260 | waypoint | 40 |
| 303 | ascend | 71 |
| 377 | getgps | 598 |
| 414 | setpoint | 4 |
| 422 | setpoint | 5 |
| 427 | descend | 71 |
| 477 | waypoint | 42 |
| 522 | ascend | 71 |
| 553 | getgps | 598 |
| 588 | setpoint | 6 |
| 599 | setpoint | 5 |
| 604 | descend | 71 |
| 664 | waypoint | 32 |
| 699 | ascend | 71 |
| 750 | getgps | 598 |
| 787 | setpoint | 4 |
| 796 | setpoint | 5 |
| 801 | descend | 71 |
| 862 | waypoint | 31 |
| 896 | ascend | 71 |
| 944 | getgps | 598 |
| 998 | exit |
Mission path
T-REX CPU usage
One can note on the mission path some strange loops when the AUV is getting its GPS fix. This in fact corresponds to the correction of the position of the AUV and was perfectly handled by T-REX which computed the new path heading accordingly.
Multiples Waypoint Execution
In this mission we specified two way points to reach with no order preferences : the west node (northing=4081.4 km, easting=597.74 km) and the north node (northing=4081.6 km, easting=597.83 km).
Plan execution
| date (seconds) | Command | Max. duration |
| 7 | setpoint | 5 |
| 12 | descend | 71 |
| 65 | waypoint(west) | 173 |
| 241 | ascend | 71 |
| 242 | getgps | 598 |
| 357 | setpoint | 5 |
| 362 | descend | 71 |
| 409 | waypoint(west) | 112 |
| 471 | waypoint(north) | 123 |
| 597 | ascend | 71 |
| 671 | getgps | 598 |
| 738 | setpoint | 5 |
| 743 | descend | 55 |
| 796 | waypoint(north) | 2 |
| 809 | exit |
Mission path
T-REX CPU usage
This mission executed successfully with a new paradigm of operation; namely making a heading change while still in the water as against coming up to surface to localize. Such changes may be useful for new kinds of missions e.g. the exploration of one particular area when a feature of interest is detected, saving energy and making the mission more efficient. However we may also need to improve our model of the position uncertainty of the AUV under such dead-reckoning situations. Until now MBARI operations considered that the AUV had to localize itself at a fixed interval but changing the heading of the AUV may increase the uncertainty in the AUV position. As a consequence, when such a situation occurs it may be preferable to reduce the interval between two check-ins. This can be computed dynamically by T-REX and will improve the behavior of the AUV.
Science and operator goals
Our next objective was to introduce science goals as the mission input for T-REX. An example of science goals could be to arm the Gulper instrument, from one node to another and fire it when an interesting feature is detected. In this mission we assumed that the AUV was droped on the center node. The objectives were :
- Science Goal 0: Do a transect from center node to north node.
- Science Goal 1: Do a transect from east node to south node.
- Operator Goal: Pickup at west node.
We expected that T-REX will plan to do the Science Goal 0 then go to the south node to execute the Science Goal 1 and finally go to its pickup point.
Unfortunately our high level model was assuming that the AUV was starting exactly at the center node. This was a strong condition resulting in an execution failure. Our next sea-trial will relax this assumption to offer more flexibility.
After few attempts we were able to be at a position that was consistent with the model the plan. Though, T-REX was just able to complete the Science Goal 0.
Plan execution
| date (seconds) | Command | Max. duration |
| 4 | setpoint | 5 |
| 9 | descend | 71 |
| 63 | waypoint_yoyo(north) | 55 |
| 121 | ascend | 67 |
| 122 | getgps | 598 |
| 231 | setpoint | 60 |
| 295 | setpoint | 5 |
| 300 | descend | 71 |
| 358 | waypoint_yoyo(north) | 54 |
| 417 | getgps | 598 |
| 456 | setpoint | 62 |
| 522 | setpoint | 5 |
| 527 | descend | 71 |
| 585 | waypoint_yoyo(north) | 54 |
| 618 | setpoint | 5 |
| 623 | descend | 16 |
| 643 | getgps | 598 |
| 644 | abort the plan |
Mission path
T-REX CPU
usage
A first analysis of the mission logs helped to conclude that the root cause of the failure was due to a squeezing of the duration bounds of a descend by a pending check-in. As a result, when the descend terminated, it had not reached its expected depth as required by the model. Thus the plan failed. This is an issue of controllability. The demands of the plan squeezed the time window for descent which included a flexible duration to reflect the inherent uncertainty of the model in this regard.
There are a number of ways we can approach this kind of a situation:
- Replan when the plan fails
- Get smarter about skipping a dive when we are so close to a check-in window
- Explicitly prohibit the shrinking of uncontrollable bounds thus recognizing the potential fault earlier
- Make the model more accurate in computing tighter bounds
- Combinations of the above
We will work actively on these issues and some other improvements to be able to do our first missions with science goals as an input instead of strictly operation related objectives.
Synopsis
In this experiment we were largely successful with some new lessons learned for the future modifications to T-REX.
All the issues detected during first trial appears to be correctly handled. All the tests from this experiment passed succesfully and repeatedly. The performance of the system was shown to have greatly improved. We still have some in-depth analysis to do to have a better understanding of the control of the AUV and intgrate this new knowledge on our AUV model.
We were able to run longer mission (around 15 minutes) and navigate through mutliple nodes. The improvements undertaken - in term of performance and robustness of our system from the first cruise, allowed us to execute the series of missions on this cruise seamlessly.